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

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

On 14/02/2017 08:04, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:amc96@xxxxxxxxxxxxxxxx] On Behalf Of Andrew 
>> Cooper
>> Sent: Tuesday, February 14, 2017 3:59 PM
>> On 14/02/2017 02:52, Tian, Kevin wrote:
>>>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>>>> Sent: Monday, February 13, 2017 10:32 PM
>>>> hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
>>>> restored when switching into guest context.  It should never have been 
>>>> part of
>>>> the migration state to start with, and Xen must not make any decisions 
>>>> based
>>>> on the value seen during restore.
>>>> Identify it as obsolete in the header files, consistently save it as zero 
>>>> and
>>>> ignore it on restore.
>>>> The MSRs must be considered dirty during VMCS creation to cause the proper
>>>> defaults of 0 to be visible to the guest.
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>, with one small comment.
>>> the effect of this patch should be more than not leaking syscall MSR.
>>> what about making the subject clearer when check-in?
>> What other effects do you think are going on here?  Yes, we now context
>> switch the MSRs right from the start of the domain, but that is
>> necessary to avoid leaking them.
> If just looking at this patch, it's for general MSR save/restore policy,
> nothing specific to syscall MSR.

The only three MSRs which use this infrastructure are LSTAR, STAR and
FMASK.  What if I were to clarify that in the first paragraph?


Xen-devel mailing list



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