From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xenproject.org
Subject: Clarification regarding Meltdown and 64-bit PV guests
Date: Sat, 13 Jan 2018 06:42:23 +0000 [thread overview]
Message-ID: <20180113064223.GT29360@bitfolk.com> (raw)
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. Guests running in 32-bit PV mode, HVM mode, and
PVH mode (both v1 and v2) cannot attack the hypervisor using
Variant 3. However, in 32-bit PV mode, HVM mode, and PVH mode
(both v1 and v2), guest userspaces can attack guest kernels
using Variant 3; so updating guest kernels is advisable.
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."
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."
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.
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).
- The guest itself remains able to use Variant 3 on its own kernel
and KPTI patches inside the guest cannot prevent this.
Which is correct, or have I misunderstood and they are somehow both
correct?
Cheers,
Andy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next reply other threads:[~2018-01-13 6:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-13 6:42 Andy Smith [this message]
2018-01-13 9:43 ` Clarification regarding Meltdown and 64-bit PV guests Hans van Kranenburg
2018-01-13 10:08 ` Andy Smith
2018-01-13 11:12 ` Hans van Kranenburg
2018-01-14 14:00 ` Dongli Zhang
2018-01-14 14:15 ` Hans van Kranenburg
2018-01-15 17:48 ` Stefano Stabellini
2018-01-14 14:05 ` Dongli Zhang
2018-01-14 14:41 ` What about dom0? (was: Re: Clarification regarding Meltdown and 64-bit PV guests) Hans van Kranenburg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180113064223.GT29360@bitfolk.com \
--to=andy@strugglers.net \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.