This security tech usually ends up in other platforms too, strongly recommend donating to their work: <a href="https://www.openbsdfoundation.org/donations.html" rel="nofollow">https://www.openbsdfoundation.org/donations.html</a>
I'm curious why Theo used a new syscall. Wouldn't it be sufficient to add a new MAP_IMMUTABLE flag to mmap which would "fix" the given range of pages' mappings and protections permanently? Can't call it MAP_FIXED sadly :-)
I was just discussing this sort of thing with some colleagues. Because the stack frame for main contains a bunch of other stuff - environment variables, cli args, etc - it makes it unreliable to try to instrument Linux systems and collect that information. A process can change its name, args, env, at any time. That sort of information is really helpful for forensics.<p>Currently your only option is to pull data directly from kernel structures, which is fine, but most people aren't doing that.<p>And then of course there's other cool stuff like being able to 'lock' system calls to the system provided libc, which openbsd can do since they already only support their provided libc.<p>Unfortunately none of this is likely to get to Linux at any point because:<p>a) I bet some insane userland processes fuck with their stacks<p>b) Linux doesn't mandate any libc<p>edit: Seems like there's some "what is this" being asked. Here's my loose understand!<p>For starters, libc is the interface to the kernel. Very few programs make syscalls directly (except go programs i guess? lol) on Linux, but on openbsd it's just flat out not allowed. OpenBSD doesn't have the "GNU/Linux" dichotomy - it's all one package deal. As such, they get to mandate how userland calls into the kernel.<p>Of course, you don't have to listen to openbsd today, because you can just... make those system calls directly. Easy. And this is relevant for security because attackers will do something called ROP, which effectively "reuses" bits of your already-executable code to issue system calls (you can google "return to libc" or "ret2libc").<p>So, first thing's first, have the kernel actually ensure that the sycall is issued from the memory that libc is mapped into. Cool, solved sort of.<p>But what if the attacker overwrites that libc? Now you've verified that the call is coming from libc but you don't have <i>integrity</i>.<p>With immutability the kernel will now enforce that system calls come from libc <i>and</i> that the code can't be overwritten.<p>Of course, this can extend beyond libc, but I'm assuming that's the main point. This would presumably be a general system call that programs can use themselves to do all sorts of fun things.<p>edit: Can't respond to replies, HN rate limited me :) sorry. Sounds like I need to read up a bit more, this doesn't address the use case I'd had in mind sadly, but still very cool nonetheless.
Url changed from <a href="https://undeadly.org/cgi?action=article;sid=20220902100648" rel="nofollow">https://undeadly.org/cgi?action=article;sid=20220902100648</a>, which points to this.