Re: Clarification regarding Meltdown and 64-bit PV guests

[Dongli Zhang <dongli.zhang@oracle.com>]

Hi Hans and Lars,

On 01/13/2018 07:12 PM, Hans van Kranenburg wrote:
> 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)

I suggest we add the source of attacker as well:

1. Arbitrary user space program on domU
2. Kernel space on domU

> 
> 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@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
> 

Dongli Zhang

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