When the inevitable ARM macintosh comes out, do you think Apple will allow W+X pages on it or do you think they'll impose W^X and call it a "security feature"
4
3
28
Conversation
Replying to
Forgive my naivete, but shouldn't an application that needs to generate code at runtime make pages that are RW, write the code, then switch permissions to RX?
2
A strong implementation prevents dynamic code generation. On Linux, this is provided by SELinux. If a process doesn't have the execmem permission, it can't create W|X mappings or transition mappings that were writable to executable, including not being able to do rw -> r -> rx.
2
It also has to be applied to files or it can be trivially bypassed via file-based mappings, by mapping the same file as writable and as executable in separate mappings. Writing to the file and mapping it as executable would also work. Strong implementations cover storage too.
1
Not permitting applications to write to anything they can execute as native code forces all native code to come through the package manager. None of this places a technical restriction on interpreted code though. It also doesn't require that all code has to come from a store.
In practice, we find interpreted code is not fast enough for some applications. It is unlikely anyone would bother running a web browser that interpreted JavaScript, for example.
1
v8 in Chromium now has a very fast interpreter and supports running without the JIT:
v8.dev/blog/ignition-
v8.dev/blog/jitless
It's usable enough that it was proposed for GrapheneOS but the performance impact is too high to do this by default.
Apple also prevents installing applications not signed by them and enforces code signing via their own keys. They enforce that all native code has to be signed by them. Safari has the lone exception. Restrictions on interpreted code are policy restrictions rather than technical.