User Profile

I'm trying to get hold of a reliable documentation for the Apple assember ('as'), especially for the M1/M2 ARM architecture, but I suspect it's similar for x86 as well. I found outdated links here: https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/Assembler/000-Introduction/introduction.html But the new documentation site for Xcode (I assume this is where I would have to look) does not seem to have assembler documentation. It's possible that apple uses the clang-llvm assembler, but it would then be nice to have an authoritative pointer to that documentation. Web searches seem futile for this subject :( Thanks for any pointers.

I'm trying to mmap a segment as both executable and writable on a newish M1 ARM64 MacBooks. That mmap fails with EACCESS errors. Mmap'ing segments with other permission bits works fine. I understand that Apple has intentionally locked down their Apple silicon machines to disallow pages marked with read and execute permissions at the same time via a policy decision (see https://github.com/zherczeg/sljit/issues/99.) I know that mprotect has already been restricted in the past, but may have allowed RWX pages with some enhanced code signing. I'd like to get an official word whether there is ANY way to turn that mmap restriction off (say, by turning SIP off, or some other tricks,) and whether we can expect this behaviour going forward. I can see that some thought has gone into supporting some JIT compilers by suggesting to switch back and forth read and execute permissions, but that suggestion won't help me.

I want to create a binary on MacOS Catalina (64 bit) with a data segment that can be made executable (see [here](https://stackoverflow.com/questions/62052528/self-modifying-code-on-macos-catalina-x64) for details), but which is not executable from the start.I make my binary with```shgcc -nostdlib -segprot __DATA rwx rw- ....```I also created an object file with gcc and then called ld directly, so this is not a gcc question but an ld question. The ld version is```sh$ ld -v@(#)PROGRAM:ld PROJECT:ld64-530BUILD 18:57:17 Dec 13 2019configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7emLTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23)TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11)```As I understand it, that *should* make the data segment initially RW, but allow me to use mprotect to extend permission in that segment to RWX.However, I notice that the __DATA segment is RW for initial and max permission:```$ otool -l jonesforth...Load command 2 cmd LC_SEGMENT_64 cmdsize 312 segname __DATA vmaddr 0x0000000100001000 vmsize 0x0000000000024000 fileoff 4096filesize 4096 maxprot 0x00000003initprot 0x00000003 nsects 3 flags 0x0Section...```Is there something I'm missing? The darwin documentation [here](http://mirror.informatimago.com/next/developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld64.1.html) says:```-segprot name max init (32-bit only) Specifies the maximum and initial virtual memory protection of the named segment, name, to be max and init ,respectively. The values for max and init are any combination of the characters `r' (for read), `w' (for write), `x' (for execute) and '-' (no access). The default is `rwx' for the maximum protection for all segments for PowerPC architecures and `rw` for the all Intel architecures. The default for the initial protection for all segments is `rw' unless the segment contains a section which contains some machine instructions, in which case the default for the initial protection is `rwx' (and for Intel architecures it also sets the maximum protection to `rwx' in this case). The default for the initial protection for the ``__TEXT'' segment is `rx' (not writable).```Of course, that the darwin (32 bit only) documentation but it's the only thing I found.I suspect that either gcc does not 'properly' support the darwin protection syntax, or it's broken, or things in darwin changed from x86 to x64.Looking at https://github.com/Apple-FOSS-Mirror/ld64/blob/30ccf3324b25680d3b08172b9f59c10d4bde2f67/ld64-134.9/src/ld/HeaderAndLoadCommands.hpp and https://github.com/Apple-FOSS-Mirror/ld64/blob/30ccf3324b25680d3b08172b9f59c10d4bde2f67/ld64-134.9/src/abstraction/MachOFileAbstraction.hpp#L417https://github.com/Apple-FOSS-Mirror/ld64/blob/30ccf3324b25680d3b08172b9f59c10d4bde2f67/ld64-134.9/src/abstraction/MachOFileAbstraction.hpp#L417 it does look like the protections are set correctly ... but they apparently are not.I'm aware that this is probably not a bug and I'm just holding it wrong, but any pointers would be great, thanks in advance.