Re: [Xen-devel] SVM/VMX and Interrupt Shadows

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/12/16 07:29, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>> Sent: Wednesday, December 14, 2016 3:25 AM
>>
>> Hello,
>>
>> All of this came about while reviewing some of Jans improvements to the
>> x86 instruction emulator.
>>
>> It turns out that the XSA-156 / CVE-2015-8104 fix, c/s bd2239d9
>> "x86/HVM: always intercept #AC and #DB", introduced an awkward bug on
>> Intel hardware.
> Please bear with my lagged response here. Need switch my context
> to fully understand this problem before I can give an answer or
> forward to internal manual owner...

No problem.  I guessed when sending this email that the answer probably
wasn't simple.

>
>> Executing a sti while singlestepping is active currently causes a
>> VMEntry failure, because the #DB is still intercepted, but on re-entry,
>> the sti interrupt shadow is still active and hardware complains about
>> invalid guest state.
> Can you specify where above VMEntry failure condition is mentioned
> in SDM?

Sadly not.  I have observed a VMEntry failure on real hardware, but
can't find the exact rule I violated.

>  The only words I found related to both STI and debug 
> exceptions are:
>
> --
> <26.3.1.5 Checks on Guest Non-Register State>
>
> The following checks are performed if any of the following holds: 
> (1) the interruptibility-state field indicates blocking by STI (bit 0 in 
> that field is 1); (2) the interruptibility-state field indicates blocking 
> by MOV SS (bit 1 in that field is 1); or (3) the activity-state field 
> indicates HLT:
>
> • Bit 14 (BS) must be 1 if the TF flag (bit 8) in the RFLAGS field is 
> 1 and the BTF flag (bit 1) in the IA32_DEBUGCTL field is 0.
> • Bit 14 (BS) must be 0 if the TF flag (bit 8) in the RFLAGS field is 
> 0 or the BTF flag (bit 1) in the IA32_DEBUGCTL field is 1.
> --
>
> Regardless of whether #DB is intercepted, shouldn't we always
> have BS set to 1 when singlestep is enabled with sti in vmentry? 
> Then what's the exact invalid guest state in your observation?

I will extend the vmcs dumping logic and try to dump all fields
referenced in this area.  Lets see what that reveals.

>> Experimentally, on both Intel and AMD hardware, the mov_ss shadow
>> inhibits #DB and the VMexit caused by its interception, whereas the sti
>> shadow doesn't inhibit #DB.  Therefore, my planned fix for VT-x is to
>> unconditionally clobber the sti shadow if we intercept #DB.  I am also
>> looking to get the behaviour correct for all hardware, and from the
>> instruction emulator.
>>
>> So my question to both AMD and Intel is how do the these shadow bits
>> actually function in real hardware? I can't find any useful information
>> in the manuals, other than rules about how to use the fields in the
>> VMCS/VMCB.
>>
>> Additionally, Intel:
>>
>> vmx_set_info_guest() clobbers the sti shadow if a debugger is attached,
>> citing a rule that eflags.TF may not be set alongside the sti shadow.  I
>> can't find any such rule in the list of vmentry checks, but then again I
>> can't find a rule which I have actually violated with the above
>> scenario.  Have I missed anything obvious?
> Honestly speaking I don't understand why it's implemented this way...
> Need to check the history to get the reason.

Sadly the history is no more enlightening.  c/s bbdcb2fd with a commit
message of only "x86, vmx: Fix single step on debugger"

I am not ruling out the possibility that the fix wasn't really correct.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel