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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251213161537.GA65365@k08j02272.eu95sqa>
Date: Sun, 14 Dec 2025 00:15:37 +0800
From: Hou Wenlong <houwenlong.hwl@...group.com>
To: Sean Christopherson <seanjc@...gle.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 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?

Thanks!