All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Alexey Kardashevskiy <aik@amd.com>
Cc: kvm@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Pankaj Gupta <pankaj.gupta@amd.com>,
	Nikunj A Dadhania <nikunj@amd.com>,
	Santosh Shukla <santosh.shukla@amd.com>,
	Carlos Bilbao <carlos.bilbao@amd.com>
Subject: Re: [PATCH kernel v5 3/6] KVM: SEV-ES: explicitly disable debug
Date: Mon, 22 May 2023 15:50:49 -0700	[thread overview]
Message-ID: <ZGvxyTyzOBod6+ki@google.com> (raw)
In-Reply-To: <20230411125718.2297768-4-aik@amd.com>

On Tue, Apr 11, 2023, Alexey Kardashevskiy wrote:
> SVM/SEV enable debug registers intercepts to skip swapping DRs
> on entering/exiting the guest. When the guest is in control of
> debug registers (vcpu->guest_debug == 0), there is an optimisation to
> reduce the number of context switches: intercepts are cleared and
> the KVM_DEBUGREG_WONT_EXIT flag is set to tell KVM to do swapping
> on guest enter/exit.
> 
> The same code also executes for SEV-ES, however it has no effect as
> - it always takes (vcpu->guest_debug == 0) branch;
> - KVM_DEBUGREG_WONT_EXIT is set but DR7 intercept is not cleared;
> - vcpu_enter_guest() writes DRs but VMRUN for SEV-ES swaps them
> with the values from _encrypted_ VMSA.
> 
> Be explicit about SEV-ES not supporting debug:
> - return right away from dr_interception() and skip unnecessary processing;
> - clear vcpu->guest_debug at SEV-ES' LAUNCH_UPDATE_VMSA if debugging
> was already enabled; after that point the generic x86's
> KVM_SET_GUEST_DEBUG ioctl disallows enabling debug.
> 
> Add WARN_ON to kvm_x86::sync_dirty_debug_regs() (saves guest DRs on
> guest exit) to signify that SEV-ES won't hit that path.
> 
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> Changes:
> v5:
> * new in the series
> ---
>  arch/x86/kvm/svm/sev.c |  6 ++++++
>  arch/x86/kvm/svm/svm.c | 10 +++++++++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 0f4761a57d86..b4365622222b 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -639,6 +639,12 @@ static int __sev_launch_update_vmsa(struct kvm *kvm, struct kvm_vcpu *vcpu,
>  	  return ret;
>  
>  	vcpu->arch.guest_state_protected = true;
> +
> +	if (vcpu->guest_debug)
> +		pr_warn_ratelimited("guest_debug (%lx) not supported for SEV-ES",

Note, this needs a newline in the printk, otherwise it'll get buffered until
the next non-cont printk comes along (guess how many times I've been burned by
this).

> +				    vcpu->guest_debug);
> +	vcpu->guest_debug = 0;

Argh, KVM's APIs can be quite frustrating.  IIUC, guest_debug can never actually
be consumed because, per Tom[*], "A guest can't run before the LAUNCH_UPDATE process
is complete".  But because the fact that the VM is an SEV-ES is communicated to
KVM after KVM_CREATE_VM, userspace can do KVM_SET_GUEST_DEBUG before KVM_SEV_ES_INIT
and before KVM_SEV_LAUNCH_UPDATE_VMSA, and thus get KVM into a state where
guest_debug is non-zero for an SEV-ES guest.  Blech.

Instead of a ratelimited warn, can KVM get away with simply rejecting
KVM_SEV_LAUNCH_UPDATE_VMSA if guest_debug is non-zero?  That combo can't work,
so it's seems unlikely userspace is relying on being able to do KVM_SET_GUEST_DEBUG.

If we do "have" to keep this approach, I'm generally opposed to any kind of printk
in KVM, but this one does seem to be justified since the most likely scenario is
that there's a human interactively debugging the guest (or at least, trying to
debug the guest).  But I would say explicitly call out the ioctl(), "guest_debug"
probably won't mean anything to a random user.  And I vote to not print the value,
that implies that the specific value is unsupported, not that debug in general is
disallowed.

Something like this (if we have to)?

		pr_warn_ratelimited("Suppressing KVM_SET_GUEST_DEBUG for SEV-ES guest\n"

[*] https://lore.kernel.org/all/7edcf2c3-005f-04bd-7ec6-80baee236f40@amd.com

> +
>  	return 0;
>  }
>  
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index dc12de325cca..179952a31d3b 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1980,7 +1980,7 @@ static void svm_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
>  {
>  	struct vcpu_svm *svm = to_svm(vcpu);
>  
> -	if (vcpu->arch.guest_state_protected)
> +	if (WARN_ON_ONCE(sev_es_guest(vcpu->kvm)))
>  		return;
>  
>  	get_debugreg(vcpu->arch.db[0], 0);
> @@ -2698,6 +2698,14 @@ static int dr_interception(struct kvm_vcpu *vcpu)
>  	unsigned long val;
>  	int err = 0;
>  
> +	/*
> +	 * SEV-ES intercepts DR7 only to disable guest debugging
> +	 * and the guest issues a VMGEXIT for DR7 write only. KVM cannot

Wrapping is a bit aggressive (wrap at 80, not earlier).

> +	 * change DR7 (always swapped as type 'A') so return early.
> +	 */
> +	if (sev_es_guest(vcpu->kvm))
> +		return 1;
> +
>  	if (vcpu->guest_debug == 0) {
>  		/*
>  		 * No more DR vmexits; force a reload of the debug registers
> -- 
> 2.39.1
> 

  reply	other threads:[~2023-05-22 22:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-11 12:57 [PATCH kernel v5 0/6] KVM: SEV: Enable AMD SEV-ES DebugSwap Alexey Kardashevskiy
2023-04-11 12:57 ` [PATCH kernel v5 1/6] KVM: SEV: move set_dr_intercepts/clr_dr_intercepts from the header Alexey Kardashevskiy
2023-04-11 12:57 ` [PATCH kernel v5 2/6] KVM: SEV: Move SEV's GP_VECTOR intercept setup to SEV Alexey Kardashevskiy
2023-04-11 12:57 ` [PATCH kernel v5 3/6] KVM: SEV-ES: explicitly disable debug Alexey Kardashevskiy
2023-05-22 22:50   ` Sean Christopherson [this message]
2023-04-11 12:57 ` [PATCH kernel v5 4/6] KVM: SVM/SEV/SEV-ES: Rework intercepts Alexey Kardashevskiy
2023-05-22 22:53   ` Sean Christopherson
2023-04-11 12:57 ` [PATCH kernel v5 5/6] KVM: SEV: Enable data breakpoints in SEV-ES Alexey Kardashevskiy
2023-05-09 10:58   ` Gupta, Pankaj
2023-05-10  9:35     ` Gupta, Pankaj
2023-05-22 23:39   ` Sean Christopherson
2023-05-23 11:33     ` Alexey Kardashevskiy
2023-05-23 15:44       ` Sean Christopherson
2023-05-26  3:16         ` Alexey Kardashevskiy
2023-05-26 14:39           ` Sean Christopherson
2023-05-30  8:57             ` Alexey Kardashevskiy
2023-06-01 23:31               ` Alexey Kardashevskiy
2023-06-13 23:19                 ` Sean Christopherson
2023-06-14  3:58                   ` Alexey Kardashevskiy
2023-06-14 21:27                     ` Sean Christopherson
2023-04-11 12:57 ` [PATCH kernel v5 6/6] x86/sev: Do not handle #VC for DR7 read/write Alexey Kardashevskiy
2023-05-22 23:44   ` Sean Christopherson
2023-05-24  6:36     ` Alexey Kardashevskiy
2023-04-20  1:49 ` [PATCH kernel v5 0/6] KVM: SEV: Enable AMD SEV-ES DebugSwap Alexey Kardashevskiy
2023-04-20 14:32   ` Sean Christopherson
2023-05-19  0:19     ` Alexey Kardashevskiy
2023-05-19 15:28       ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZGvxyTyzOBod6+ki@google.com \
    --to=seanjc@google.com \
    --cc=aik@amd.com \
    --cc=carlos.bilbao@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikunj@amd.com \
    --cc=pankaj.gupta@amd.com \
    --cc=santosh.shukla@amd.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.