linux-kernel - Re: [PATCH 2/2] KVM: x86: Open code all direct reads to guest DR6 and DR7

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: <19824d6d-28f9-4aa0-8b10-bacefc49adfd@grsecurity.net>
Date: Fri, 9 Feb 2024 23:30:26 +0100
From: Mathias Krause <minipli@...ecurity.net>
To: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: x86: Open code all direct reads to guest DR6 and
 DR7

On 09.02.24 23:07, Sean Christopherson wrote:
> Bite the bullet, and open code all direct reads of DR6 and DR7.  KVM
> currently has a mix of open coded accesses and calls to kvm_get_dr(),
> which is confusing and ugly because there's no rhyme or reason as to why
> any particular chunk of code uses kvm_get_dr().
> 
> The obvious alternative is to force all accesses through kvm_get_dr(),
> but it's not at all clear that doing so would be a net positive, e.g. even
> if KVM ends up wanting/needing to force all reads through a common helper,
> e.g. to play caching games, the cost of reverting this change is likely
> lower than the ongoing cost of maintaining weird, arbitrary code.
> 
> No functional change intended.
> 
> Cc: Mathias Krause <minipli@...ecurity.net>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
>  arch/x86/kvm/smm.c        | 8 ++++----
>  arch/x86/kvm/vmx/nested.c | 2 +-
>  arch/x86/kvm/x86.c        | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/smm.c b/arch/x86/kvm/smm.c
> index 19a7a0a31953..d06d43d8d2aa 100644
> --- a/arch/x86/kvm/smm.c
> +++ b/arch/x86/kvm/smm.c
> @@ -194,8 +194,8 @@ static void enter_smm_save_state_32(struct kvm_vcpu *vcpu,
>  	for (i = 0; i < 8; i++)
>  		smram->gprs[i] = kvm_register_read_raw(vcpu, i);
>  
> -	smram->dr6     = (u32)kvm_get_dr(vcpu, 6);
> -	smram->dr7     = (u32)kvm_get_dr(vcpu, 7);
> +	smram->dr6     = (u32)vcpu->arch.dr6;
> +	smram->dr7     = (u32)vcpu->arch.dr7;
>  
>  	enter_smm_save_seg_32(vcpu, &smram->tr, &smram->tr_sel, VCPU_SREG_TR);
>  	enter_smm_save_seg_32(vcpu, &smram->ldtr, &smram->ldtr_sel, VCPU_SREG_LDTR);
> @@ -236,8 +236,8 @@ static void enter_smm_save_state_64(struct kvm_vcpu *vcpu,
>  	smram->rip    = kvm_rip_read(vcpu);
>  	smram->rflags = kvm_get_rflags(vcpu);
>  
> -	smram->dr6 = kvm_get_dr(vcpu, 6);
> -	smram->dr7 = kvm_get_dr(vcpu, 7);
> +	smram->dr6 = vcpu->arch.dr6;
> +	smram->dr7 = vcpu->arch.dr7;
>  
>  	smram->cr0 = kvm_read_cr0(vcpu);
>  	smram->cr3 = kvm_read_cr3(vcpu);
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 28d1088a1770..d05ddf751491 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -4433,7 +4433,7 @@ static void sync_vmcs02_to_vmcs12(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12)
>  		(vm_entry_controls_get(to_vmx(vcpu)) & VM_ENTRY_IA32E_MODE);
>  
>  	if (vmcs12->vm_exit_controls & VM_EXIT_SAVE_DEBUG_CONTROLS)
> -		vmcs12->guest_dr7 = kvm_get_dr(vcpu, 7);
> +		vmcs12->guest_dr7 = vcpu->arch.dr7;
>  
>  	if (vmcs12->vm_exit_controls & VM_EXIT_SAVE_IA32_EFER)
>  		vmcs12->guest_ia32_efer = vcpu->arch.efer;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bfffc13f91e6..5a08d895bde6 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5510,7 +5510,7 @@ static void kvm_vcpu_ioctl_x86_get_debugregs(struct kvm_vcpu *vcpu,
>  	for (i = 0; i < ARRAY_SIZE(vcpu->arch.db); i++)
>  		dbgregs->db[i] = vcpu->arch.db[i];
>  
> -	dbgregs->dr6 = kvm_get_dr(vcpu, 6);
> +	dbgregs->dr6 = vcpu->arch.dr6;
>  	dbgregs->dr7 = vcpu->arch.dr7;
>  }
>  

Reviewed-by: Mathias Krause <minipli@...ecurity.net>

Nice cleanup. Thanks a lot, Sean!