RE: meltdown

["Terry Moore" <tmm%mcci.com@localhost>]

> 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.
>
> People seem to be mentioning a 50% performance penalty and we might do
> worse (we don't have vDSOs...)

I suggest sticking to the original papers which are at meltdownattack.com:

https://meltdownattack.com/meltdown.pdf
and 
https://spectreattack.com/spectre.pdf

The problems are fairly subtle.

They demonstrated (in the Meltdown paper) that you can use JIT compiled code
(they used JavaScript in Chrome) to read anything in the Chrome processes'
memory. The kernel memory exploit is troubling, but actually easier to
mitigate. It looks relatively *easier* to mitigate the kernel/user
separation problem.  I think more thought needs to go into how this effects
sandboxing approaches (JIT, interpreters, Docker, XEN, etc). JIT, docker,
Xen are all mentioned as having difficulties.

If I understand the paper correctly, the K/U space unmapping must be
accompanied on x86 (32/64) by KASLR; otherwise the things that must always
be mapped in U space (trap handlers, etc.) can be used to get access anyway.

I don't think you need to SEGV to get this data - the SEGVs can be on the
speculative ("predicted taken") branch path, but the branch is not actually
taken, so the SEGV never gets reported. However, the cache state is changed
by the speculative path.

But really: we all need to read the primary papers, and not pay too much
attention to the press about this.... the press discussion is not really
very helpful (at least as of this morning EDT).

--Terry