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

Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs

On 25/04/2018 07:49, Jan Beulich wrote:
>>>> On 24.04.18 at 20:51, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, 
>> uint64_t *msr_content)
>>      switch ( msr )
>>      {
>>      case MSR_IA32_SYSENTER_CS:
>> +    case MSR_IA32_SYSENTER_ESP:
>> +    case MSR_IA32_SYSENTER_EIP:
> These three do not require sync-ing, as their values aren't read from the 
> (They do require sync-ing on the write path).

See the TODO list in the patch comment.  This is a quirk of cross-vendor
logic being used unnecessarily in the common case, and isn't going to
remain like this.

> I also don't think this is going to fully resolve Razvan's issue (not the 
> least
> because the code paths you adjust aren't involved in his scenario): As
> pointed out in a private mail, I think vmcb_in_sync needs to start out as
> true for a vCPU, and may need setting to true upon context set and/or
> reset/init emulation.

No - it wont, but its obviously broken and will be the second bug to be
hit by introspection, when interception of these MSRs is active.

It just so happened that it was the easier issue to get started with.


Xen-devel mailing list



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