* Ingo Molnar <mingo@xxxxxxxxxx> wrote: > I really don't like it where this is going. In a couple of years I > really want to be able to think of PTI as a bad dream that is mostly > over fortunately. > > I have the feeling that compiler level protection that avoids > corrupting the stack in the first place is going to be lower overhead, > and would work in a much broader range of environments. Do we have > analysis of what the compiler would have to do to prevent most ROP > attacks, and what the runtime cost of that is? > > I mean, C# and Java programs aren't able to corrupt the stack as long > as the language runtime is corect. Has to be possible, right? So if such security feature is offered then I'm afraid distros would be strongly inclined to enable it - saying 'yes' to a kernel feature that can keep your product off CVE advisories is a strong force. To phrase the argument in a bit more controversial form: If the price of Linux using an insecure C runtime is to slow down system calls with immense PTI-alike runtime costs, then wouldn't it be the right technical decision to write the kernel in a language runtime that doesn't allow stack overflows and such? I.e. if having Linux in C ends up being slower than having it in Java, then what's the performance argument in favor of using C to begin with? ;-) And no, I'm not arguing for Java or C#, but I am arguing for a saner version of C. Thanks, Ingo