[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 01/13/2018 07:42 AM, Andy Smith wrote:
> Hi,
> 
> In
> <https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/>:
> 
>     "On Intel processors, only 64-bit PV mode guests can attack Xen
>     using Variant 3. [...]

64bit PV domU userspace can attack the hypervisor -> read "host memory"
which also contains contents of guest memory (including itself)

>     Interestingly, guest kernels running in 64-bit PV mode are not
>     vulnerable to attack using Variant 3, because 64-bit PV guests
>     already run in a KPTI-like mode."

64-bit PV domU userspace can't attack kernel inside guest
Quoting Andrew C (on IRC): "the 64bit PV ABI already has split
guest-user / guest-kernel pagetables; (because 64bit x86 took away
working segment limits from the 32bit world); it mitigates guest
userspace SP3 attacks against the guest kernel"

This is also the reason for adding the if-statement which prevents the
new kpti code from becoming active when booting your latest kernel in a
64-bit PV domU.

> However, in multiple other places, including
> <https://xenbits.xen.org/xsa/xsa254/README.comet> and
> <https://xenbits.xen.org/xsa/xsa254/README.vixen>:
> 
>     "Note that both of these shim-based approaches prevent attacks on
>     the host, but leave the guest vulnerable to Meltdown attacks by
>     its own unprivileged processes; this is true even if the guest
>     OS has KPTI or similar Meltdown mitigation."

So, even while it can't attack itself inside the guest, it can make a
"detour" over the hypervisor to again read its own memory.

> These seem to contradict each other.
> 
> The FAQ seems to suggest that:
> 
> - 32-bit PV guest userland processes can use Variant 3 against their
>   own kernels and that the KPTI patch would protect against that.
> 
> - Without Comet/Vixen, 64-bit PV guests can't use Variant 3 on
>   themselves but can use it on the hypervisor, and KPTI patches in
>   the guest do not prevent that.

^^

> - Running PV guests inside Comet or Vixen prevents them making use
>   of Variant 3, they still cannot use Variant 3 against their own
>   kernels, and KPTI patches in the guest are not necessary.

Like it was for a long time already, because of the "64bit PV ABI
already has split [...]"

> The Comet and Vixen READMEs seem to suggest that:
> 
> - Use of Comet/Vixen prevents PV guests from using Variant 3 against
>   the hypervisor (and thus other guests as well).

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".

> - The guest itself remains able to use Variant 3 on its own kernel
>   and KPTI patches inside the guest cannot prevent this.

This one should be incorrect.

> Which is correct, or have I misunderstood and they are somehow both
> correct?

It's complicated. At least, the above is what I understood.

Hans

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.