lkml.org 
[lkml]   [2019]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2019-04-26 11:58    [W:0.119 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site