One way to potentially work around this is to allow the stack
pages to be marked executable by explicit linking with an
alternate crt0.o, or, more usefully, by way of an attribute on
the file (e.g. a "chflags").
Is there some reason that we should not do this by way of a syscall that the
particular process calls? If an exploit is at a point where it can run
syscalls, I'd think we are screwed anyway, and we should know at compile time
what programs would need this and not, if we do it globally. The only problem
is legacy programs that need this.
This is how as crt0/1 fix would *have to* work. It's the kernel
that makes the decision on stack page mappings, and on stack
growth (through the fault handler for the guard page).
The reason this was less useful than a file attribute is that it
would have to be called explicitly. The default would have to be
"allowed", with the call being "relinquish". That's why it would
need the compiler option O'Brian was talking about implementing,
if I hacked up ctr1 for him. It would be like being root by
default in all programs, and having to call "setuid" to become
non-root, which also makes it undesirable.
I think this is heading down into the implementation details, and
it's important to keep it at a higher level for right now, so I
won't comment on the rest...
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message