Messages in this thread | | | Date | Fri, 26 Apr 2019 11:58:02 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation |
| |
* Ingo Molnar <mingo@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
| |