All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Wanpeng li <wanpeng.li@hotmail.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest
Date: Thu, 19 Nov 2015 12:05:25 +0100	[thread overview]
Message-ID: <564DACF5.9090908@redhat.com> (raw)
In-Reply-To: <BLU436-SMTP15906F5C0F0430EFB140F45801B0@phx.gbl>



On 19/11/2015 11:45, Wanpeng li wrote:
> Intel cpu doesn't support syscall/sysret in non 64-bit mode which 
> is different from AMD. Expose syscall/sysret to intel 32-bit guest 
> just makes no sense and leads to #UD which will confuse the users. 
> 
> This patch disable expose syscall/sysret to intel 32-bit guest.
> 
> Signed-off-by: Wanpeng li <wanpeng.li@hotmail.com>
> ---
>  arch/x86/kvm/cpuid.c | 16 ++++++++++++++++
>  arch/x86/kvm/x86.c   |  1 +
>  2 files changed, 17 insertions(+)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 6525e92..f8ddca6 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -62,6 +62,7 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_cpuid_entry2 *best;
>  	struct kvm_lapic *apic = vcpu->arch.apic;
> +	bool vendor_intel = false;
>  
>  	best = kvm_find_cpuid_entry(vcpu, 1, 0);
>  	if (!best)
> @@ -114,6 +115,21 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
>  	vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
>  
>  	kvm_pmu_refresh(vcpu);
> +
> +	/* Don't expose syscall/sysret to intel non 64-bit mode guest */
> +	best = kvm_find_cpuid_entry(vcpu, 0x00000000, 0x00000000);
> +	if (best && best->ebx == 0x756e6547 && best->ecx == 0x6c65746e &&
> +		best->edx == 0x49656e69)
> +		vendor_intel = true;

You can use X86EMUL_CPUID_VENDOR_GenuineIntel_ebx/ecx/edx instead here.

> +	best = kvm_find_cpuid_entry(vcpu, 0x80000001, 0);
> +	if (best && vendor_intel) {
> +		if (!is_long_mode(vcpu))
> +			best->edx &= ~F(SYSCALL);
> +		else
> +			best->edx |= F(SYSCALL);

This is not correct.  As far as I know, the SYSCALL bit is always
present in CPUID, even if the machine is running in 32-bit mode; CPUID
documentation (SDM Volume 2) explicitly documents bit 11 as "Bit 11:
SYSCALL/SYSRET available in 64-bit mode".

So there are two possibilities here:

1) Clear F(SYSCALL) in kvm_update_cpuid, like you are doing here but
only if F(LM) is already clear (in addition to the vendor being Intel).

2) do nothing, declare this a userspace bug.  Linux knows that only AMD
machines support SYSCALL in 32-bit mode (there is a separate feature bit
X86_FEATURE_SYSCALL32 that is only set by arch/x86/kernel/cpu/amd.c).
Are you fixing an issue with Windows?  If so, with what QEMU command
line?  But if it's not an issue with a real guest, doing nothing would
be my favorite option...

In any case, set_efer doesn't need to call kvm_update_cpuid.

Thanks,

Paolo

       reply	other threads:[~2015-11-19 11:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BLU436-SMTP15906F5C0F0430EFB140F45801B0@phx.gbl>
2015-11-19 11:05 ` Paolo Bonzini [this message]
2015-11-19 12:01   ` [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest Wanpeng Li
2015-11-19 12:02     ` Paolo Bonzini
2015-11-25 12:45   ` Wanpeng Li
2015-11-25 13:27     ` Paolo Bonzini

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=564DACF5.9090908@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wanpeng.li@hotmail.com \
    /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.