linux-kernel - Re: [PATCH v2 1/2] x86/traps: Initialize DR6 by writing its architectural reset value

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: <alpine.DEB.2.21.2506190607470.37405@angie.orcam.me.uk>
Date: Thu, 19 Jun 2025 06:16:22 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Sean Christopherson <seanjc@...gle.com>
cc: Sohil Mehta <sohil.mehta@...el.com>, "Xin Li (Intel)" <xin@...or.com>, 
    linux-kernel@...r.kernel.org, kvm@...r.kernel.org, tglx@...utronix.de, 
    Ingo Molnar <mingo@...hat.com>, bp@...en8.de, dave.hansen@...ux.intel.com, 
    x86@...nel.org, hpa@...or.com, pbonzini@...hat.com, peterz@...radead.org, 
    brgerst@...il.com, tony.luck@...el.com, fenghuay@...dia.com
Subject: Re: [PATCH v2 1/2] x86/traps: Initialize DR6 by writing its
 architectural reset value

On Tue, 17 Jun 2025, Sean Christopherson wrote:

> Yeah, the name is weird, but IMO DR6_INIT or DR6_RESET aren't great either.  I'm
> admittedly very biased, but I think KVM's DR6_ACTIVE_LOW better captures the
> behavior of the bits.  E.g. even if bits that are currently reserved become defined
> in the future, they'll still need to be active low so as to be backwards compatible
> with existing software.

 FWIW I'd call this macro DR6_DEFAULT, to keep it simple and explicitly 
express our intent here (we want to set our default after all).

 I think reusing DR6_ACTIVE_LOW could be risky, regardless of its KVM use, 
because there's no guarantee the semantics of a future architectural 
addition will match the name, i.e. the value of 0 may actually *disable* 
what we currently have always enabled and while technically this could 
count as "feature active", this double-negation might just make one's head 
spin unnecessarily.  Plus we may actually want to have that stuff disabled 
by default then.

  Maciej