Hacker News Reader

Comment by basementcat | Hacker News Reader

Looks like this may break some JIT's? Or is the workaround to have the JIT'ed code call libc instead of making direct syscalls?

View on HN

OpenBSD already prevents syscalls from writable pages. It did not break JITs, in fact, to quote Theo de Raadt, it brings over an aspect of W^X to JITs that haven't been adapted to work with mandatory W^X.

https://marc.info/?l=openbsd-cvs&m=155942895309114&w=2

This means it's forced to use the libc stubs for syscalls. Any direct syscall from a JIT is suspect.

Hmm. Do any JITs actually emit syscalls directly? I would’ve guessed most JITs won’t even emit direct libc calls directly, since there tends to be layers of abstraction between it and the software.

Indeed. This appears to be the case for stuff encountered thus far.

QEMU does for its user-mode-only code, but not in JITted code. We have a little shim that directly executes a syscall instruction because we want to be able to wind the PC forward/backward across it to avoid a race condition with a signal arriving after the guest thinks it's made the syscall but before we've made the syscall in the host. But that's currently only done by linux-user; bsd-user should ideally have a similar mechanism but is basically dead/dying for lack of maintainers who care about the BSDs. In any case, that falls under "in the binary's text segment" rather than JIT output.

(code at https://git.qemu.org/?p=qemu.git;a=blob;f=linux-user/host/x8... )

Reply on news.ycombinator.com