Re: Clarification regarding Meltdown and 64-bit PV guests

[Hans van Kranenburg <hans@knorrie.org>]

On 14/01/2018 15:00, Dongli Zhang wrote:
> 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.

Yes.

For reference, I looked back at my IRC logs. This is the related
conversation about it, #xen IRC on freenode, from Jan 6 2018, when I was
firing off questions to Andrew.

18:17 < Knorrie> with Xen 4.8+ and the pvshim method for non-pvh guest
kernels, is the xen implementation that does the same as KPTI inside the
guest for 64bit PV still present?
18:20 < andyhhp> hmm
18:20 < Knorrie> I think that's an interesting questino :)
18:20 < andyhhp> the 64bit PV ABI already has an isolation between guest
userspace and guest kernel
18:20 < andyhhp> so in effect, has had KPTI for 12 years already...
18:21 < andyhhp> however
18:21 < andyhhp> Xen's mappings are not currently isolated, so either
guest userspace or guest kernel can attack Xen using SP3/Meltdown
18:22 < Knorrie> yes, as I understood the reason of the pvshim feature
was to fix exactly that
18:23 < andyhhp> the Linux KPTI feature should turn itself off when it
detects it is running as a PV guest under Xen
18:24 < andyhhp> but this was quite late to the party, and it appears
that Redhat have published an update to RHEL 6.x which bricks PV guests :(
18:24 < Knorrie> ah right, I remember having seen that if statement one
of these days yes
18:24 < Knorrie> so no need to manually turn  it off in exactly that
scenario
18:26 < andyhhp> the PV-shim doesn't do anything clever
18:26 < andyhhp> all we do is stick a second version of Xen in there
18:26 < andyhhp> so we've got L0 Xen running a PVH guest (so in an HVM
container).
18:26 < andyhhp> that PVH guest is actually a Xen running a single
legacy PV guest
18:27 < Knorrie> well, the clever things is that you can't see outside
of your own memory any more right
18:27 < Knorrie> s/things/thing/
18:27 < andyhhp> the alteration is/should/will be transparent from the
point of view of the legacy PV guest
18:28 < andyhhp> the legacy PV guest can still attempt to pull off
SP3/Meltdown attacks, but they stop at the L1 Xen
18:29 < andyhhp> so all it can do is do is read details relating to
itself.  It can't read anything belonging to other VMs
18:29 < Knorrie> like, outgoing network traffic from other processes on
the same guest?
18:29 < Knorrie> (regardless of how practical and realistic those
attacks are)

---- >8 ----

18:30 < andyhhp> it should be noted that PV-SHIM isn't a perfect
replacement for some kind of Xen based KPTI solution.  A piece of
userspace inside the PV guest can still use SP3 to attack othe
r processes by bypassing the PV guest kernel and attacking via L1 Xen
18:30 < andyhhp> but that is a darn sight better than having said piece
of PV guest userspace being able to read every VM on the entire system

---- >8 ----

18:31 < Knorrie> yes
18:32 < andyhhp> however, I've come to the executive decision that Xen
can't do some kind of KPTI-based solution without a change in the PV ABI
18:32 < andyhhp> because PV guests currently have too much control over
their pagetables for Xen to implement KPTI behind them
18:34 < Knorrie> sounds like this is the moment when PV is going to be
declared dead
18:34 < Knorrie> well
18:34 < Knorrie> of course there's hardware that cannot do PVH
18:35 < Knorrie> but I mean, for who can do PVH whenever they're updated
to recent guest kernels the changes would come even later again, so for
them it's the PVH way
18:36 < Knorrie> and PV remains half-broken for a longer time for who cant
18:36 < andyhhp> PV isn't dead by any means, and I'm going to refuse to
declare it so
18:37 < andyhhp> there are still legitimate (and indeed, modern)
usecases where PV guests will unconditionally always outperform HVM guests
18:38 < andyhhp> but all such usecases have the PV guests at least in
the semi-TCB

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