[RFC PATCH 2/7] x86/sci: add core implementation for system call isolation

[Ingo Molnar]

* Ingo Molnar <mingo at kernel.org> 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