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

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 2018-01-09 15:04, Stefano Stabellini wrote:
On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
> On 05/01/18 18:16, Rich Persaud wrote:
> >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@xxxxxxxxx
> >> <mailto:lars.kurth.xen@xxxxxxxxx>> wrote:
> >> Linux’s KPTI series is designed to address SP3 only.  For Xen guests,
> >> only 64-bit PV guests are affected by SP3. A KPTI-like approach was
> >> explored initially, but required significant ABI changes.  

Is some partial KPTI-like approach feasible? Like unmapping memory owned
by other guests, but keeping Xen areas mapped? This will still allow
leaking Xen memory, but there are very few secrets there (vCPUs state,
anything else?), so overall impact will be much lower.


I believe https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ is clear re VMs attacking/accessing the host/dom0/hypervisor and the mitigations for that.

However the page seems ambiguous about whether 64 bit VMs running as PVHv2 with host provided kernels are protected or not (from each VM's own processes).

Can the page be updated to be more explicit and perhaps describe how the VM kernel or how the PVHv2 virtualization provides that protection. And ideally how that could be checked from the VM itself. e.g. grep pti /proc/cpuinfo?

e.g. the page says: "Guest kernels running in 64-bit PV mode are not directly vulnerable to attack using SP3, because 64-bit PV guests already run in a KPTI-like mode." but it does not mention PVHv2 for that. Is it protected under PVHv2? Does it depend on the kernel? Is so what is the patchset/option/mechanism that protects the VM from its own processes?

Xen-devel mailing list



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