linux-kernel - Re: [PATCH kernel v5 4/6] KVM: SVM/SEV/SEV-ES: Rework intercepts

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: <ZGvygxYiKBD1Y8Zn@google.com>
Date:   Mon, 22 May 2023 15:53:55 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Alexey Kardashevskiy <aik@....com>
Cc:     kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
        Tom Lendacky <thomas.lendacky@....com>,
        Pankaj Gupta <pankaj.gupta@....com>,
        Nikunj A Dadhania <nikunj@....com>,
        Santosh Shukla <santosh.shukla@....com>,
        Carlos Bilbao <carlos.bilbao@....com>
Subject: Re: [PATCH kernel v5 4/6] KVM: SVM/SEV/SEV-ES: Rework intercepts

On Tue, Apr 11, 2023, Alexey Kardashevskiy wrote:
> Currently SVM setup is done sequentially in
> init_vmcb() -> sev_init_vmcb() -> sev_es_init_vmcb()
> and tries keeping SVM/SEV/SEV-ES bits separated. One of the exceptions
> is DR intercepts which is for SEV-ES before sev_es_init_vmcb() runs.
> 
> Move the SEV-ES intercept setup to sev_es_init_vmcb(). From now on
> set_dr_intercepts()/clr_dr_intercepts() handle SVM/SEV only.
> 
> No functional change intended.
> 
> Suggested-by: Sean Christopherson <seanjc@...gle.com>
> Signed-off-by: Alexey Kardashevskiy <aik@....com>
> Reviewed-by: Santosh Shukla <santosh.shukla@....com>
> Reviewed-by: Tom Lendacky <thomas.lendacky@....com>
> ---
> Changes:
> v5:
> * updated the comments
> * removed sev_es_guest() checks from set_dr_intercepts()/clr_dr_intercepts()
> * removed remaining intercepts from clr_dr_intercepts()
> ---
>  arch/x86/kvm/svm/sev.c | 11 ++++++
>  arch/x86/kvm/svm/svm.c | 37 ++++++++------------
>  2 files changed, 25 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index b4365622222b..f0885250252d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -2946,6 +2946,7 @@ int sev_es_string_io(struct vcpu_svm *svm, int size, unsigned int port, int in)
>  
>  static void sev_es_init_vmcb(struct vcpu_svm *svm)
>  {
> +	struct vmcb *vmcb = svm->vmcb01.ptr;
>  	struct kvm_vcpu *vcpu = &svm->vcpu;
>  
>  	svm->vmcb->control.nested_ctl |= SVM_NESTED_CTL_SEV_ES_ENABLE;
> @@ -2974,6 +2975,16 @@ static void sev_es_init_vmcb(struct vcpu_svm *svm)
>  	svm_set_intercept(svm, TRAP_CR4_WRITE);
>  	svm_set_intercept(svm, TRAP_CR8_WRITE);
>  
> +	/*
> +	 * DR7 access must remain intercepted for an SEV-ES guest to disallow
> +	 * the guest kernel enable debugging as otherwise a VM writing to DR7
> +	 * from the #DB handler may trigger infinite loop of #DB's.

This is wrong.  The attack isn't writing DR7 in the #DB handler, it's setting up
a #DB on memory that's needed to vector a #DB, e.g. the stack, so that the _CPU_
itself gets stuck in an infinite #DB loop[*].  The guest software handler putting
itself into an infinite loop is a non-issue because it can be interrupted.

[*] https://bugzilla.redhat.com/show_bug.cgi?id=1278496

> +	 */
> +	vmcb->control.intercepts[INTERCEPT_DR] = 0;
> +	vmcb_set_intercept(&vmcb->control, INTERCEPT_DR7_READ);
> +	vmcb_set_intercept(&vmcb->control, INTERCEPT_DR7_WRITE);
> +	recalc_intercepts(svm);