@kmeisthax My understanding is that they’re trying to annoy people who can influence control flow such that they can create a controlled state for an arbitrary syscall by making it so that the legitimate syscall instructions in the address space are tied to their number

@kmeisthax Personally I don’t think this is particularly worth the trouble but I get the impression that their threat model is that the last time they tried to remove syscall instructions from outside of libc people told them it was easy enough to ROP there

@kmeisthax (I am still not entirely clear what this is trying to protect against because presumably all the syscall wrappers that libc has still exist in the address space? The “number” field that this is trying to protect does not look very valuable)

@kmeisthax (Like, the goal seems to be “oh the attacker cannot put an arbitrary thing in rax and jump to a syscall instruction”. But like libc *by design* has to have gadgets that load it up with basically any valid syscall number…)

@saagar I suspect OpenBSD plans to change its libc to not have that kind of gadget and instead have a separate wrapper per syscall. They can do that because OpenBSD does NOT make any KABI promises whatsoever (unlike Linux).

This is also why Go keeps breaking on OpenBSD. I suspect that might also be part of their threat model...

@kmeisthax This is going to break applications that use dlsym to look up symbols in libc though

@kmeisthax Like if you take this to its logical conclusion it’s just “applications should specify which system calls they use” which is literally just what pledge does and it’s enforced by the kernel and not in some weird ad-hoc IP to syscall number lookup scheme