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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 
> VMCB.
> (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.

~Andrew

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