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

Re: [Xen-devel] [PATCH] x86/VT-x: Don't activate VMCS Shadowing outside of nested vmx mode



>>> On 07.12.18 at 21:07, <andrew.cooper3@xxxxxxxxxx> 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 <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>



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

 


Rackspace

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