Re: [PATCH v15 02/12] x86/hw_breakpoints: Make DR7 updates NMI safe

On Mon, 07 Sep 2026 04:00:16 +0000
sashiko-bot@kernel.org wrote:

quoted

diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h
index 854d82b88ff4e..3399e166d3044 100644
--- a/arch/x86/include/asm/debugreg.h
+++ b/arch/x86/include/asm/debugreg.h

[ ... ]

quoted

@@ -125,40 +126,66 @@ static __always_inline bool hw_breakpoint_active(void)
 
 extern void hw_breakpoint_restore(void);
 
-static __always_inline unsigned long local_db_save(void)
+static __always_inline void local_db_save(unsigned long *dr7,
+					  unsigned int *dr7_seq)
 {
-	unsigned long dr7;
+	do {
+		*dr7_seq = this_cpu_read(cpu_dr7_seq);
+		*dr7 = 0;
 
-	if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR) && !hw_breakpoint_active())
-		return 0;
-
-	get_debugreg(dr7, 7);
+		if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR) &&
+		    !hw_breakpoint_active())
+			return;

[Severity: High]
This isn't a bug introduced by this patch, but could this early return
in local_db_save() bypass the sequence retry loop?

If an NMI hits exactly before the return instruction and installs a
breakpoint, the function exits immediately. This leaves the newly installed
hardware breakpoint active during exception handlers like MCE, which could
trigger a recursive #DB exception and lead to a kernel panic.

Wait... but fixing this may leak the DR7 setting to the guest. We need another
patch to solve this, which introduce a per-cpu flag to prohibit updating the
DR7 during switching to the guest.

Thanks,

-- 
Masami Hiramatsu (Google) [off-list ref]