Hi Hans, 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.
Does this indicate that there is no solution to prevent a malicious user space program (running on 64-bit PV domU) from reading the memory of domU kernel space (via meltdown), no matter whether comet/vixen is enabled or not? Therefore, comet/vixen is only used to prevent the cross-VM meltdown attack. > >> 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@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