On 10/12/2018 16:01, Jan Beulich wrote: >>>> On 07.12.18 at 21:07, <[email protected]> wrote: >> By default on capable hardware, SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is >> activated unilaterally. The VMCS Link pointer is initialised to ~0, but the >> VMREAD/VMWRITE bitmap pointers are not. >> >> This causes the 16bit IVT and Bios Data Area get interpreted as the >> read/write >> permission bitmap for guests which blindly execute VMREAD/VMWRITE >> instructions. >> >> This is not a security issue because the VMCS Link pointer being ~0 causes >> VMREAD/VMWRITE to complete with VMFailInvalid (rather than modifying a >> potential shadow VMCS), and the contents of MFN 0 has already been determined >> not to contain any interesting data because of L1TF's ability to read that 4k >> frame. >> >> Leave VMCS Shadowing disabled by default, and toggle it in >> nvmx_{set,clear}_vmcs_pointer(). This isn't the most efficient course of >> action, but it is the most simple way of leaving nested-virt working as it >> did >> before. >> >> While editing construct_vmcs(), collect all default secondary_exec_control >> modifications together. The disabling of PML is latently buggy because it >> happens after secondary_exec_control are written into the VMCS, although >> there >> is an unconditional update later which writes the correct value into >> hardware. >> >> Signed-off-by: Andrew Cooper <[email protected]> > Reviewed-by: Jan Beulich <[email protected]>
As this is blocking staging, I'm committing it right now. If there are further concerns, I'll happily address them in a followup patch. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
