Re: meltdown

[<Paul.Koning%dell.com@localhost>]

> On Jan 4, 2018, at 4:58 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> As I understand it, on intel cpus and possibly more, we'll need to
>> unmap the kernel on userret, or else userland can read arbitrary
>> kernel memory.
> 
> "Possibly more"?  Anything that does speculative execution needs a good
> hard look, and that's damn near everything these days.
> 
>> Also, I understand that to exploit this, one has to attempt to access
>> kernel memory a lot, and SEGV at least once per bit.
> 
> I don't think so.  Traps that would be taken during normal execution
> are not taken during speculative execution.  The problem is, to quote
> one writeup I found, "Intel CPUs are allowed to access kernel memory
> when performing speculative execution, even when the application in
> question is running in user memory space.  The CPU does check to see if
> an invalid memory access occurs, but it performs the check after
> speculative execution, not before.".  This means that things like cache
> line loads can occur based on values the currently executing process
> should not be able to access; timing access to data that cache-collides
> with the cache lines of interest reveals the leaked bit(s).
> 
> Nowhere in there is a SEGV generated.

That depends.  The straightforward case of Meltdown starts with an
illegal load, which the CPU will execute anyway speculatively, resulting
in downstream code execution that can be used to change the cache state.
In that form, the load eventually aborts.

There's a discussion in the paper that the load could be preceded by
a branch not taken that's predicted taken.  If so, the SEGV would indeed
not happen, but it isn't clear how feasible this is.

In any case, the problem would not occur in any CPU that does protection
checks prior to issuing speculative memory references.  

	paul