[Xen-devel] L1TF, and future work

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Hello,

Now that the embargo on XSA-273 is up, we can start publicly discussing
the remaining work do, because there is plenty to do.  In no particular
order...

1) Attempting to shadow dom0 from boot leads to some assertions very
very quickly.   Shadowing dom0 after-the-fact leads to some very weird
crashes where whole swathes of the shadow appears to be missing.  This
is why, for now, automatic shadowing of dom0 is disabled by default.

2) 32bit PV guests which use writeable pagetable support will
automatically get shadowed when the clear the lower half.  Ideally, such
guests should be modified to use hypercalls rather than the ptwr
infrastructure (as its more efficient to begin with), but we can
probably work around this in Xen by emulating the next few instructions
until we have a complete PTE (same as the shadow code).

3) Toolstack CPUID/MSR work.  This is needed for many reasons.
3a) Able to level MSR_ARCH_CAPS and maxphysaddr to regain some migration
safety.
3b) Able to report accurate topology to Xen (see point 5) and to guests.
3c) Able to configure/level the Viridian leaves, and implement the
Viridian L1TF extension.
3d) Able to configure/level the Xen leaves and implement a similar L1TF
enlightenment.

4) The shadow MMIO fastpath truncates the MMIO gfn at 2^28 without any
indication of failure.  The most compatible bugfix AFACIT would be to
add an extra nibble's worth of gfn space which gets us to 2^32, and
clamp the guest maxphysaddr calculation at 44 bits.  The alternative is
to clamp maxphysaddr to 40 bits, but that will break incoming migrate of
very large shadow guests.

4a) The shadow MMIO fastpath needs a runtime clobber, because it will
not function at all on Icelake hardware with a 52-bit physical address
width.  Also, it turns out there is an architectural corner case when
levelling maxphysaddr, where some bits which (v)maxphysaddr says should
elicit #PF[RSVD], don't because the actual pipeline address width is larger.

5) Core-aware scheduling.  At the moment, Xen will schedule arbitrary
guest vcpus on arbitrary hyperthreads.  This is bad and wants fixing. 
I'll defer to Dario for further details.

Perhaps the more important longer term action is to start removing
secrets from Xen, because its getting uncomfortably easy to ex-filtrate
data.  I'll defer to David for his further plans in this direction.

I'm sure I've probably missed something in all of this, but this is
enough to begin the discussion.

~Andrew

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