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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
