Re: [Xen-devel] Clarification regarding Meltdown and 64-bit PV guests

[Hans van Kranenburg <hans@xxxxxxxxxxx>]

On 01/13/2018 11:08 AM, Andy Smith wrote:
> Hi Hans,
> 
> On Sat, Jan 13, 2018 at 10:43:03AM +0100, Hans van Kranenburg wrote:
>> By injecting a copy of a hypervisor between the outer level hypervisor
>> (that's called L0 right?) (in HVM or PVH mode) and the guest, having it
>> just run 1 guest, that (64-bit PV) guest cannot attack its own kernel,
>> but it can attack the intermediate hypervisor which results in reading
>> it's own memory from the fake intermediate "host memory".
> 
> So are you saying that, considering only SP3/Variant 3/Meltdown, it
> works out like this:
> 
> == 64-bit PV mode guest ==
> 
> - Can't use SP3/Variant 3/Meltdown directly on its own kernel.
> 
> - Can use SP3/Variant 3/Meltdown on the hypervisor to read data from
>   hypervisor so effectively everything including other kernels and
>   its own kernel.
> 
> - Can't be mitigated by KPTI in the guest.
> 
> == PV-in-Comet and PV-in-Vixen ==
> 
> - Can't use SP3/Variant 3/Meltdown directly on its own kernel
> 
> - Can't use SP3/Variant 3/Meltdown on the real hypervisor.
> 
> - Can still use SP3/Variant 3/Meltdown on the shim hypervisor to
>   still gain access to data from itself.
> 
> - Can't be mitigated by KPTI in the guest.
> 
> == HVM and PVHv2 ==
> 
> - Can use SP3/Variant 3/Meltdown directly on its own kernel.
> 
> - Can't use SP3/Variant 3/Meltdown on the hypervisor.
> 
> - Can be mitigated by KPTI in the guest (becomes not a Xen issue).
> 
> ?

Exactly.

> If so, then I can see how the FAQ, README.Comet and README.Vixen
> can all be correct in this regard,

Well, what just happened is that I didn't provide any new information,
but presented the same information by just rewording it again, which
triggered a few missing connections to complete your mental image.

> but do note that this is extremely confusing

Yes it is.

A. Different types of Xen versions:
  1. <= 4.5, which is EOL and EOS, but still used (like AWS popping up
having things running based on Xen 3.4)
  2. 4.6 and 4.7, which have some security support
  3. 4.8 and 4.9, for which rumours are going that it might get PVHv2
from 4.10 backported
  4. 4.10, which can be used with PVHv2 (with guest kernel linux 4.14)

B. Different archs:
  1. x86 / 32-bit
  2. x64 / amd64 / 64-bit
  3. Add ARM things here...
  4. ...

C. Different CPU vendors:
  1. Intel
  2. AMD
  3. ...

D. Then different virtualization modes:
  1. PV
  2. HVM
  3. PVHv2

E. Different mitigation techniques for Xen (which are each only possible
with a subset of choices from other categories):
  1. Convert PV -> HVM
  2. Convert PV -> PVHv2
  3. Insert shim Vixen
  4. Insert shim Comet

F. Different kernels in the guest (only looking at linux here now):
  1. Any kernel released < Jan 3 2018
  2. Old version without any kaiser/kpti patch available
  3. Old version with kaiser backport patch (3.2, 3.16, 4.9 etc)
  4. 4.14 or 4.15 kernel with KPTI patch

G. Different mitigation techniques for inside the guest:
  1. Do nothing because 64-bit PV guest
  2. Get kernel with kaiser or kpti patch

H. And of course describing any situation as "vulnerable" has a
shortcoming, because we need to distinguish (4 combinations possible):
  1. Can the situation be used to attack?
  2. Is the situation vulnerable to attack by another guest/whatever?

ad H. Oh, and what if someone has a mix of HVM and PV guests? If there
are only HVM guests, they're safe from each other, but if you add 1
64-bit PV guest to it, suddenly you have one available to do an attack,
and all the HVM are suddenly vulnerable.

So it's a bit of an 7 or 8-dimensional space, and every situation of
different users is floating somewhere in there as a point. Every
combination of all of those can result in a wildly different outcome.

Oh wait, I forgot we're only talking about SP3. Let's add SP1 and SP2,
now we are 9-dimensional.

You know these kind of puzzles?
http://www.burre.nl/p/puzzels/logisch/logisch_1.gif

It's what we're doing here. :-) Well, instead of a boolean result, our
puzzle has multiple results, describing what's relevant for hypervisor,
for guest kernel etc...

> and a lot of people are only reading the
> comments that say that Xen PV can't make use of SP3/Variant
> 3/Meltdown.

Expressing all these things in text is really hard.

Lars made a new attempt with the tables, but you immediately see it
takes 4 or 5 tables below each other, and then it's still like "argh!"
because we can't flatten 8-dimensional to 2-dimensional that easy.

------------ >8 ------------

So, I have a new idea:

Let's make an interactive html/javascript thingie where you can play
around with all the combinations above. Based on everything you choose,
there's a different explanation as result, and different suggestions
about what to do next...

Some of the categories are radio buttons, like the CPU type of the
physical server. Others are checkboxes with multiple options, e.g. are
you running HVM guests, PV guests, or both?

I'm not a html/javascript guy, but I think that makes most sense, since
a user can also just git clone the thing and open the page in a local
browser. If there's some initial code that works, I can help adding all
options and results and then we can keep improving it. (E.g. if
limitations of shim implementations change or xen 4.8 and 4.9 get PVHv2
backported, it has to change again etc...)

Nice to have: If you have everything checked in the right way, show a
"code" (like A3-B1-C5-D6... or something more clever) that expresses the
exact combination, so you can save it and put it back in later to reset
the page to that state. And, you can share that code/sequence to explain
your exact situation to someone else.

Now we would have something that's easier to work with than hearing a
user out with 14 questions on IRC and then trying to explain everything
in words. Any change you make on the page refreshes the outcome immediately.

So, who has a better idea than this, or knows why this is a bad idea and
we shouldn't do this, or who wants to help creating it?

Hans

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel