Hacker News Reader

Comment by kevingadd | Hacker News Reader

Registers aren't resources you access through syscalls, there's no way for the kernel to control them unless you're running under virtualization or the CPU architecture specifically allows access control for the register. (As the site notes, virtualization allows controlling access to this register)

View on HN

Can kernel scan each page it maps as executable and return an error if it finds instructions interacting with the 'bad' register? Assuming the kernel requires executable pages to be read-only (W^X), this may even be doable (but probably very very slow).

> Assuming the kernel requires executable pages to be read-only (W^X)

Which macOS's kernel doesn't.

It does require that, but it allows flipping between RX and RW at will (for JITs), and the M1 actually has proprietary features to allow userspace to do this without involving the kernel, so the kernel couldn't re-scan when those flips happen (plus it would kill performance anyway).

Plus, as I said above, this is prone to false positives anyway because the executable section on ARM also includes constant pools.

Can't a MAP_JIT region be writable by one thread and executable by a different thread at the same time?

https://developer.apple.com/documentation/apple-silicon/port...

That link confirms that it can:

> Because pthread_jit_write_protect_np changes only the current thread’s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region.

Ah, yes, I forgot about that. So indeed there is no non-racy hook point for the kernel to do such a check, even if it made sense and the RX/RW switch went through the kernel, which it doesn't.

Reply on news.ycombinator.com