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

Message-ID: <7480bb12-60a5-45ab-acb5-14f35c3f4782@zytor.com>
Date: Wed, 18 Jun 2025 14:55:55 -0700
From: Xin Li <xin@...or.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Sohil Mehta <sohil.mehta@...el.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, tglx@...utronix.de, 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 6/18/2025 2:24 PM, Sean Christopherson wrote:
> On Tue, Jun 17, 2025, Xin Li wrote:
>> On 6/17/2025 1:47 PM, Sean Christopherson wrote:
>>> On Tue, Jun 17, 2025, Sohil Mehta wrote:
>>> Note, DR6_VOLATILE and DR6_FIXED_1 aren't necessarily aligned with the current
>>> architectural definitions (I haven't actually checked),
>>
>> I'm not sure what do you mean by "architectural definitions" here.
> 
> I was trying to say that there may be bits that have been defined in the SDM,
> but are not yet makred as "supported" in DR6_VOLATILE, i.e. that are "incorrectly"
> marked as DR6_FIXED_1 (in quotes, because from KVM's perspective, the bits *are*
> fixed-1, for the guest).

Clear for me now, thanks for the explanation.

Wanted to echo that it's necessary to be in a KVM mindset sometimes.

>   
>> However because zeroing DR6 leads to different DR6 values depending on
>> whether the CPU supports BLD:
>>
>>    1) On CPUs with BLD support, DR6 becomes 0xFFFF07F0 (bit 11, DR6.BLD,
>>       is cleared).
>>
>>    2) On CPUs without BLD, DR6 becomes 0xFFFF0FF0.
>>
>> DR6_FIXED_1, if it is still defined to include all bits that can't be
>> cleared, is a constant value only on a *specific* CPU architecture,
>> i.e., it is not a constant value on all CPU implementations.
>>
>>
>>> rather they are KVM's
>>> view of the world, i.e. what KVM supports from a virtualization perspective.
>>
>> So KVM probably should expose the fixed 1s in DR6 to the guest depending on
>> which features, such as BLD or RTM, are enabled and visible to the
>> guest or not?
>>
>> (Sorry I haven't looked into how the macro DR6_FIXED_1 is used in KVM,
>> maybe it's already used in such a way)
> 
> Yep, that's exactly what KVM does.  DR6_FIXED_1 is the set of bits that KVM
> doesn't yet support for *any* guest.  The per-vCPU set of a fixed-1 bits starts
> with DR6_FIXED_1, and adds in bits for features that aren't supported/exposed
> to the guest.
> 
> static u64 kvm_dr6_fixed(struct kvm_vcpu *vcpu)
> {
> 	u64 fixed = DR6_FIXED_1;
> 
> 	if (!guest_cpu_cap_has(vcpu, X86_FEATURE_RTM))
> 		fixed |= DR6_RTM;
> 
> 	if (!guest_cpu_cap_has(vcpu, X86_FEATURE_BUS_LOCK_DETECT))
> 		fixed |= DR6_BUS_LOCK;
> 	return fixed;
> }

Excellent!

KVM is aware of BLD and behaves the same as real hardware, doing a
better job than native regarding this specific case.