Contributed by Paul 'WEiRD' de Weerd on from the stacks-of-mitigations dept.
Recently, Theo de Raadt (deraadt@) described a new type of mitigation he has been working on together with Stefan Kempf (stefan@):
How about we add another new permission! This is not a hardware
permission, but a software permission. It is opportunistically
enforced by the kernel.
the permission is MAP_STACK. If you want to use memory as a stack,
you must mmap it with that flag bit. The kernel does so automatically
for the stack region of a process's stack. Two other types of stack
occur: thread stacks, and alternate signal stacks. Those are handled
in clever ways.
When a system call happens, we check if the stack-pointer register
points to such a page. If it doesn't, the program is killed. We
have tightened the ABI. You may no longer point your stack register
at non-stack memory. You'll be killed. This checking code is MI, so
it works for all platforms.
For more detail, see Theo's original message.
This is now available in snapshots, and people are finding the first problems in the ports tree already. So far, few issues have been uncovered, but as Theo points out, more testing is necessary:
Fairly good results. A total of 4 problems have been found so far. go, SBCL, and two cases in src/regress which failed the new page-alignement requirement. The SBCL and go ones were found at buildtime, since they use themselves to complete build. But more page-alignment violations may be found in ports at runtime. This is something I worry about a bit. So please everyone out there can help: Use snapshots which contain the stack-check diff, update to new packages, and test all possible packages. Really need a lot of testing for this, so please help out.
So, everybody, install the latest snapshot and try all your favorite ports. This is the time to report issues you find, so there is a good chance this additional security feature is present in 6.3 (and works with third party software from packages).
(Comments are closed)