On 04/27/2018 02:53 PM, speck for Linus Torvalds wrote:
> 
> 
> On Fri, 27 Apr 2018, speck for Thomas Gleixner wrote:
> 
>> On Fri, 27 Apr 2018, speck for Linus Torvalds wrote:
> 
>>> 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.
>>
>> Fair enough. I didn't look at it that way. Thanks for the clarification.
> 
> NOTE! My reading of the worry people have about the store buffer bypass 
> attack may simply be wrong. So somebody should verify this part.

The concern we have is about managed code, yeah. I didn't want to fight
too hard on the unset part if we get the set bit :) but there shouldn't
be a security issue to having the prctl go both ways (and that would be
ideal IMO). It's really about a sandboxed JavaScript or Java process (or
somesuch similar like thing) in which that JIT is not expecting the
potential for code to abuse this bypass to dump memory from the process
containing it. e.g. in JavaScript you can make a memory dumping widget
in about three lines of code that runs speculatively for that process.

> Because if the store buffer bypass is actually seen as a security issue on 
> its own, then your argument that people shouldn't be able to turn the 
> mitigation off is obviously very valid.

It /might/ be an issue for the kernel stack. This is the fear many of us
have. However, we do an lfence on entry to the kernel, so it would only
be a problem there if we can find vulnerable syscall functions, and we
haven't yet found any that contain suitable gadgets. That seems
contrived, but it's the reason for the original kernel entry/exit frob.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop