Re: [PATCH v2] Linux Patch 1/1

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 27 Apr 2018, speck for Linus Torvalds wrote:
> On Fri, 27 Apr 2018, speck for Thomas Gleixner wrote:
> > On Fri, 27 Apr 2018, speck for Thomas Gleixner wrote:
> > > 
> > > Sure. You set it on that sandbox thing and then the thread which is spawned
> > > of from there can disable it. Brilliant idea.
> > 
> > And in fact you want it even inherit on exec because then you can start the
> > JVM or whatever you want to protect with it disabled and never have to
> > worry about it again.
> 
> I don't think that's the attack people are worried about.
> 
> Basically, for the store buffer bypass, the *only* worry is JIT'ed code. 
> I don't think people expect it to leak from supervisor to user mode, for 
> example, so it's not primarily a protection domain issue.
> 
> It's almost purely a "I generated code assuming the architecture would 
> actualy execute the code I wrote" issue.
> 
> That means that it's not like you're really executing "untrusted" code in 
> general. Your jitted code isn't going to just run random sysctl's without 
> any checking or anything like that. You trust your JVM to take care of 
> *those* kinds of security issues.
> 
> So "user can turn it on and off as they please" is not really an issue. In 
> fact, it could easily be seen as a feature. Making it expensive or hard to 
> turn off the mitigation means that you can't necessarily just turn it on 
> temporarily for the code you really care about.
> 
> Realistically, a JIT would probably prefer to only turn off store buffer 
> bypass when jumping into JIT'ed code, and then turning it on when coming 
> back. Exactly because it's really not about any "security", it's abnout "I 
> translated untrusted code, and I want _exactly_ the semantics that I did 
> the translations with - everything else I can and do check manually".

Fair enough. I didn't look at it that way. Thanks for the clarification.

Thanks,

	tglx