Hi Martin, > 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.
Avoiding the root cause of the problem is practically impossible, even the so called "safe" languages didn't turn out to be as safe as claimed after all... So anything that is simple and free is absolutely worth doing, and far more useful than mitigations that just slow things down but don't really improve security. The _chk variants of various string functions are a total waste of time for example and give a false sense of security. And yet people waste a large amount of effort optimizing them in assembler code, even creating ifuncs for them etc... > I am a bit surprised that the static chain register is not > always already a fixed part of the ABI. Why? If every language or extension needed several special ABI registers you'd run out of registers pretty quickly and the ABI would be too complex to implement. The this-pointer in C++ doesn't need a special ABI register - likewise a static chain is just an extra argument. >> 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. Yes we could just pick a register now since this feature won't be used much. Wilco
