* Ingo Molnar [off-list ref] 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