[RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
mingo at kernel.org
Fri Apr 26 09:58:02 UTC 2019
* 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.
More information about the Linux-security-module-archive