Hi Wilco, Am Donnerstag, den 13.12.2018, 16:33 +0000 schrieb Wilco Dijkstra: > Uecker, Martin wrote: > > Am Mittwoch, den 12.12.2018, 22:04 +0000 schrieb Wilco Dijkstra: > > > Hi Martin, > > > > > > > Does a non-executable stack actually improve security? > > > > > > Absolutely, it's like closing your front door rather than just leave it > > > open > > > for anyone. > > > > The question is whether it is like closing the front door > > while leaving a window open. It makes it harder to > > exploit a system but does not really prevent it. > > Security is never absolute, it's all about making it harder and more expensive > for attackers so they go after other, easier targets.
One could also argue that it creates a false sense of security and diverts resources from properly fixing the real problems i.e. the buffer overflows which lets an attacker write to the stack in the first place. A program without buffer overflows is secure even without an executable stack and a program with buffer overflows is still insecure even with a non-executable stack. > > It was implemented for Ada. But here is a patch to also > > activate it for C: > > > > https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00853.html > > > > With this patch one can use nested functions in C without > > having an executable stack. > > I tried your patch and it seems to inline the code to load the static chain > at every > indirect callsite. For Ada I don't think that is ABI (IIRC no separate > compilation), > but for C it would create a new ABI. I am a bit surprised that the static chain register is not always already a fixed part of the ABI. > > but it wouldn't affect the ABI since you can > > only take the address of a nested function when you're > > the parent function. > > But you can pass the address to another function. Without > > trampolines, this other function needs to call the nested > > function directly using the right ABI. > > Yes that was a really bad idea - function pointers with a > descriptor should be explictly typed to avoid the need to > use special trampolines. This is essentially what Apple's block extension does. The downside is that you cannot pass such pointers to existing code. > If we didn't want to expose the static chain register as an ABI > with -fno-trampolines, we could use a helper function which could > be made backwards compatible even if one changes the static chain > register (it just needs to set all of them!). Yes, this is a possibility. But I think it could simply be fixed as part of the ABI. Best, Martin
