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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

> 
> 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? 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?


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

> 
> AMD: Despite observably different behaviour, the VMCB only has a single
> bit for shadowing.  Will the hardware mov_ss shadow always inhibit all
> #DB activity, including instruction breakpoints on the following
> instruction?  If not, I can't see a way to safely fix this.
> 
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel