linux-kernel - Re: [PATCH 4/7] KVM: x86: Consolidate KVM_GUESTDBG_SINGLESTEP check into the kvm_inject_emulated

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]

Message-ID: <aUH8wcu4zRclhYUn@google.com>
Date: Tue, 16 Dec 2025 16:43:45 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Hou Wenlong <houwenlong.hwl@...group.com>
Cc: kvm@...r.kernel.org, Lai Jiangshan <jiangshan.ljs@...group.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/7] KVM: x86: Consolidate KVM_GUESTDBG_SINGLESTEP check
 into the kvm_inject_emulated_db()

On Sun, Dec 14, 2025, Hou Wenlong wrote:
> On Fri, Dec 12, 2025 at 09:53:20AM -0800, Sean Christopherson wrote:
> > On Fri, Dec 12, 2025, Hou Wenlong wrote:
> > > On Thu, Dec 11, 2025 at 09:19:39AM -0800, Sean Christopherson wrote:
> > > > On Thu, Dec 11, 2025, Hou Wenlong wrote:
> > > > +static noinline unsigned long singlestep_with_code_db(void)
> > > > +{
> > > > +	unsigned long start;
> > > > +
> > > > +	asm volatile (
> > > > +		"lea 1f(%%rip), %0\n\t"
> > > > +		"mov %0, %%dr2\n\t"
> > > > +		"mov $" xstr(DR7_FIXED_1 | DR7_EXECUTE_DRx(2) | DR7_GLOBAL_ENABLE_DR2) ", %0\n\t"
> > > > +		"mov %0, %%dr7\n\t"
> > > > +		"pushf\n\t"
> > > > +		"pop %%rax\n\t"
> > > > +		"or $(1<<8),%%rax\n\t"
> > > > +		"push %%rax\n\t"
> > > > +		"popf\n\t"
> > > > +		"and $~(1<<8),%%rax\n\t"
> > > In my previous understanding, I thought there would be two #DBs
> > > generated at the instruction boundary. First, the single-step trap #DB
> > > would be handled, and then, when resuming to start the new instruction,
> > > it would check for the code breakpoint and generate a code fault #DB.
> > > However, it turns out that the check for the code breakpoint happened
> > > before the instruction boundary. 
> > 
> > Yeah, that's what I was trying to explain by describing code breakpoint as fault-like.
> > 
> > > I also see in the kernel hardware breakpoint handler that it notes that code
> > > breakpoints and single-step can be detected together. Is this due to
> > > instruction prefetch?
> > 
> > Nope, it's just how #DBs work, everything pending gets smushed together.  Note,
> > data #DBs can also be coincident.  E.g. it's entirely possible that you could
> > observe a code breakpoint, a data breakpoint, and a single-step breakpoint in a
> > single #DB.
> > 
> > > If we want to emulate the hardware behavior in the emulator, does that
> > > mean we need to check for code breakpoints in kvm_vcpu_do_single_step()
> > > and set the DR_TRAP_BITS along with the DR6_BS bit?
> > 
> > Hmm, ya, I think so?  I don't think the CPU will fetch and merge the imminent
> > code #DB with the injected single-step #DB.
> Um, I have one more question: what do you mean when you say that
> kvm_vcpu_check_code_breakpoint() doesn't account for RFLAGS.TF?

I was pointing out that if KVM is emulating multiple instructions without
entering the guest, then I'm pretty sure kvm_vcpu_check_code_breakpoint() would
fail to detect a coincident single-step #DB.  kvm_vcpu_check_code_breakpoint()
may not be the right place to try and handle that though.