All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Lai Jiangshan <jiangshanlai@gmail.com>, linux-kernel@vger.kernel.org
Cc: Lai Jiangshan <laijs@linux.alibaba.com>,
	Sean Christopherson <seanjc@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: X86: Also reload the debug registers before kvm_x86->run() when the host is using them
Date: Thu, 8 Jul 2021 18:48:21 +0200	[thread overview]
Message-ID: <46e0aaf1-b7cd-288f-e4be-ac59aa04908f@redhat.com> (raw)
In-Reply-To: <20210628172632.81029-1-jiangshanlai@gmail.com>

On 28/06/21 19:26, Lai Jiangshan wrote:
> From: Lai Jiangshan <laijs@linux.alibaba.com>
> 
> When the host is using debug registers but the guest is not using them
> nor is the guest in guest-debug state, the kvm code does not reset
> the host debug registers before kvm_x86->run().  Rather, it relies on
> the hardware vmentry instruction to automatically reset the dr7 registers
> which ensures that the host breakpoints do not affect the guest.
> 
> But there are still problems:
> 	o The addresses of the host breakpoints can leak into the guest
> 	  and the guest may use these information to attack the host.

I don't think this is true, because DRn reads would exit (if they don't, 
switch_db_regs would be nonzero).  But otherwise it makes sense to do at 
least the DR7 write, and we might as well do all of them.

> 	o It violates the non-instrumentable nature around VM entry and
> 	  exit.  For example, when a host breakpoint is set on
> 	  vcpu->arch.cr2, #DB will hit aftr kvm_guest_enter_irqoff().
> 
> Beside the problems, the logic is not consistent either. When the guest
> debug registers are active, the host breakpoints are reset before
> kvm_x86->run(). But when the guest debug registers are inactive, the
> host breakpoints are delayed to be disabled.  The host tracing tools may
> see different results depending on there is any guest running or not.

More precisely, the host tracing tools may see different results 
depending on what the guest is doing.

Queued (with fixed commit message), thanks!

Paolo

> To fix the problems, we also reload the debug registers before
> kvm_x86->run() when the host is using them whenever the guest is using
> them or not.
> 
> Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
> ---
>   arch/x86/kvm/x86.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index b594275d49b5..cce316655d3c 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -9320,7 +9320,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>   	if (test_thread_flag(TIF_NEED_FPU_LOAD))
>   		switch_fpu_return();
>   
> -	if (unlikely(vcpu->arch.switch_db_regs)) {
> +	if (unlikely(vcpu->arch.switch_db_regs || hw_breakpoint_active())) {
>   		set_debugreg(0, 7);
>   		set_debugreg(vcpu->arch.eff_db[0], 0);
>   		set_debugreg(vcpu->arch.eff_db[1], 1);
> 


  reply	other threads:[~2021-07-08 16:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 17:26 [PATCH] KVM: X86: Also reload the debug registers before kvm_x86->run() when the host is using them Lai Jiangshan
2021-07-08 16:48 ` Paolo Bonzini [this message]
2021-07-09  3:09   ` Lai Jiangshan
2021-07-09  9:49     ` Paolo Bonzini
2021-07-09 10:05       ` Lai Jiangshan
2021-07-09 15:52         ` Paolo Bonzini
2021-07-09 16:35           ` Jim Mattson
2021-07-09 16:58             ` Paolo Bonzini
2021-07-09 17:01               ` Jim Mattson
2021-07-09 16:49   ` 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=46e0aaf1-b7cd-288f-e4be-ac59aa04908f@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jiangshanlai@gmail.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=laijs@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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.