Classic thread on this stuff from Halvar Flake:<p><a href="https://twitter.com/halvarflake/status/1156815950873804800" rel="nofollow noreferrer">https://twitter.com/halvarflake/status/1156815950873804800</a><p>With that in mind, it'd be handy to know which exploit techniques these steps break, and whether those steps are in the current "meta" game for exploit developers.<p>(The specific mitigation here: the kernel formerly locked system call invocation down to the libc.so area of program text in memory; libc.so is big, so now OpenBSD locks specific system calls down to their specified libc stubs; further, in static binaries, the same mechanism locks programs down to only those system calls used in the binary, which effectively disables all the system calls not explicitly invoked by the program text of a static binary).
Without a pre-formed opinion: does anybody have an intuition for the security benefits this provides? My first thought is that it’s primarily mitigating cases of attacker-introduced shellcode, which should already be pretty well covered by techniques like W^X. Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right?<p>I would also think this would cause problems for JITed code, although maybe syscalls in JITed code aren’t common enough for this to be an issue (or the JIT gets around it by calling a syscall thunk, similar to how Go handled OpenBSD’s earlier syscall changes).
> in ld.so text, and in that case the main program's text cannot do system calls<p>I don’t understand this case. Is there a way to do IO in openbsd without a system call? Without IO how can you get the result of the computation?<p>Is this a singular special case?