The new OpenBSD `mimmutable()` call, when applied on the stack, does absolutely nothing to prevent writing or reading the stack. It prevents changing the (virtual memory/pagetable) mapping itself, i.e. mapping in something else, removing the mapping, or changing the mapping attributes (primarily RWX).
Even if some userland process requires an executable stack, that would be indicated with ELF flags and set up by the loader - and then frozen in place.
…
Actually, now that I think about it, I guess you could try to put the boundary between main() and the magic bits right on a page boundary, and then change attrs on the magic bits?
Right, yeah.
> It would probably break the ANSI C standard though if you can't modify argv and environ though.
AFAIK it would also break setproctitle(), unless my memory is off that works by just writing over the argv space.
On the plus side, on Linux /proc/<pid>/environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.)
prctl(PR_SET_MM_ENV_{START,END}) will change the contents of /proc/<pid>/environ.
From what it looks like in Linux's source code, twiddling the bits at the base of the stack will also cause the procfs file to change--it seems to read directly from the process's memory. Ditto for /cmdline and /auxv, it seems.
… but Thanks for removing a misconception of mine!
Neither does OpenBSD. You're misunderstanding how msyscall() works. It's like Highlander. There can be only one.
You’re forgetting statically compiled binaries, which are very important for ease of deployment and distro-agnostic execution.
What do you mean by "insane" here? In standard C you get char** argv, and the arguments live on the stack. I believe you are allowed to modify those cli arguments through the pointers, it is not undefined behavior.
You’ve just described why system call integrity is useless without strong CFI :)
Currently your only option is to pull data directly from kernel structures, which is fine, but most people aren't doing that.
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.
Unfortunately none of this is likely to get to Linux at any point because:
a) I bet some insane userland processes fuck with their stacks
b) Linux doesn't mandate any libc
edit: Seems like there's some "what is this" being asked. Here's my loose understand!
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.
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").
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.
But what if the attacker overwrites that libc? Now you've verified that the call is coming from libc but you don't have integrity.
With immutability the kernel will now enforce that system calls come from libc and that the code can't be overwritten.
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.
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.