linux-kernel - Re: [PATCH 8/9] KVM: x86, SVM: do not clobber guest DR6 on KVM_EXIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 6 May 2020 16:47:46 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Peter Xu <peterx@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH 8/9] KVM: x86, SVM: do not clobber guest DR6 on
 KVM_EXIT_DEBUG

On Wed, May 06, 2020 at 07:33:06PM -0400, Peter Xu wrote:
> On Wed, May 06, 2020 at 02:20:47PM -0700, Sean Christopherson wrote:
> > On Wed, May 06, 2020 at 05:13:56PM -0400, Peter Xu wrote:
> > > Oh... so is dr6 going to have some leftover bit set in the GD test if without
> > > this patch for AMD?  Btw, I noticed a small difference on Intel/AMD spec for
> > > this case, e.g., B[0-3] definitions on such leftover bits...
> > > 
> > > Intel says:
> > > 
> > >         B0 through B3 (breakpoint condition detected) flags (bits 0 through 3)
> > >         — Indicates (when set) that its associated breakpoint condition was met
> > >         when a debug exception was generated. These flags are set if the
> > >         condition described for each breakpoint by the LENn, and R/Wn flags in
> > >         debug control register DR7 is true. They may or may not be set if the
> > >         breakpoint is not enabled by the Ln or the Gn flags in register
> > >         DR7. Therefore on a #DB, a debug handler should check only those B0-B3
> > >         bits which correspond to an enabled breakpoint.
> > > 
> > > AMD says:
> > > 
> > >         Breakpoint-Condition Detected (B3–B0)—Bits 3:0. The processor updates
> > >         these four bits on every debug breakpoint or general-detect
> > >         condition. A bit is set to 1 if the corresponding address- breakpoint
> > >         register detects an enabled breakpoint condition, as specified by the
> > >         DR7 Ln, Gn, R/Wn and LENn controls, and is cleared to 0 otherwise. For
> > >         example, B1 (bit 1) is set to 1 if an address- breakpoint condition is
> > >         detected by DR1.
> > > 
> > > I'm not sure whether it means AMD B[0-3] bits are more strict on the Intel ones
> > > (if so, then the selftest could be a bit too strict to VMX).
> > 
> > If the question is "can DR6 bits 3:0 be set on Intel CPUs even if the
> > associated breakpoint is disabled?", then the answer is yes.  I haven't
> > looked at the selftest, but if it's checking DR6 then it should ignore
> > bits corresponding to disabled breakpoints.
> 
> Currently the selftest will also check that the B[0-3] is cleared when specific
> BP is disabled.  We can loose that.  The thing is this same test can also run
> on AMD hosts, so logically on the other hand we should still check those bits
> as cleared to follow the AMD spec (and it never failed for me even on Intel..).

There still has to be an address and type match, e.g. if the DRs are
completely bogus in the selftest then the "cleard to zero" check is still
valid.  And if I'm reading the selftest code correctly, this is indeed the
case as only the DRn being tested is configured.