Re: [PATCH] KVM: VMX: Set vmcs.PENDING_DBG.BS on #DB in STI/MOVSS blocking shadow

[Sean Christopherson]

On Thu, Jan 20, 2022, Andrew Cooper wrote:
> On 20/01/2022 00:06, Sean Christopherson wrote:
> > MOVSS blocking can be initiated by userspace, but can be coincident with
> > a #DB if and only if DR7.GD=1 (General Detect enabled) and a MOV DR is
> > executed in the MOVSS shadow.  MOV DR #GPs at CPL>0, thus MOVSS blocking
> > is problematic only for CPL0 (and only if the guest is crazy enough to
> > access a DR in a MOVSS shadow).  All other sources of #DBs are either
> > suppressed by MOVSS blocking (single-step, code fetch, data, and I/O),
> 
> It is more complicated than this and undocumented.  Single step is
> discard in a shadow, while data breakpoints are deferred.

But for the purposes of making the consitency check happy, whether they are
deferred or dropped should be irrelevant, no?
 
> > are mutually exclusive with MOVSS blocking (T-bit task switch),
> 
> Howso?  MovSS prevents external interrupts from triggering task
> switches, but instruction sources still trigger in a shadow.

T-bit #DBs are traps, and arrive after the task switch has completed.  The switch
can be initiated in the shadow, but the #DB will be delivered after the instruction
retires and so after MOVSS blocking goes away.  Or am I missing something?

  The processor generates a debug exception after a task switch if the T flag of the
  new task's TSS is set. This exception is generated after program control has passed
  to the new task, and prior to the execution of the first instruction of that task.

> >  or are
> > already handled by KVM (ICEBP, a.k.a. INT1).
> 
> Other sources of #DB include RTM debugging, with errata causing a
> fault-style #DB pointing at the XBEGIN instruction, rather than
> vectoring to the abort handler

Ugh, I forgot about RTM.  That mess should also be mutually exclusive.  CLI/STI and
modifying segment registers cause abort, and XBEGIN in the shadow wouldn't activate
the region until XBEGIN retires and the shadow goes away.

> and splitlock which is new since I last thought about this problem.

Eww.  Split Lock is trap-like, which begs the question of what happens if the
MOV/POP SS splits a cache line when loading the source data.  I'm guess it's
suppressed, a la data breakpoints, but that'd be a fun one to test.

> > This bug was originally found by running tests[1] created for XSA-308[2].
> > Note that Xen's userspace test emits ICEBP in the MOVSS shadow, which is
> > presumably why the Xen bug was deemed to be an exploitable DOS from guest
> > userspace.
> 
> As I recall, the original report to the security team was something
> along the lines of "Steam has just updated game, and now when I start
> it, the VM explodes".

Lovely.  I wonder if the game added some form of anti-cheat?  I don't suppose you
have disassembly from the report?  I'm super curious what on earth a game would
do to trigger this.

> >   KVM already handles ICEBP by skipping the ICEBP instruction
> > and thus clears MOVSS blocking as a side effect of its "emulation".
> >
> > [1] http://xenbits.xenproject.org/docs/xtf/xsa-308_2main_8c_source.html
> 
> This URL is at the whim of doxygen and not necessarily stable.
> 
> https://xenbits.xen.org/gitweb/?p=xtf.git;a=blob;f=tests/xsa-308/main.c
> ought to have better longevity, as well as including test description.

Thanks!