All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jeff_Zimmerman@McAfee.com
Cc: lars.kurth.xen@gmail.com, xen-devel@lists.xenproject.org,
	lars.kurth@xen.org, Ian.Campbell@citrix.com, JBeulich@suse.com
Subject: Re: Intermittent fatal page fault with XEN 4.3.1 (Centos 6.3 DOM0 with linux kernel 3.10.16.)
Date: Thu, 7 Nov 2013 15:54:18 +0000	[thread overview]
Message-ID: <527BB7AA.4080801@citrix.com> (raw)
In-Reply-To: <24B7017F-1AC7-4900-93EB-F54C11002491@McAfee.com>

On 07/11/13 15:41, Jeff_Zimmerman@McAfee.com wrote:
> On Nov 7, 2013, at 1:30 AM, Ian Campbell <Ian.Campbell@citrix.com>
>  wrote:
>
>> On Thu, 2013-11-07 at 09:10 +0000, Jan Beulich wrote:
>>>>>> On 06.11.13 at 18:07, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> On 06/11/13 17:06, Ian Campbell wrote:
>>>>> On Wed, 2013-11-06 at 16:54 +0000, Andrew Cooper wrote:
>>>>>> I looked over the xl code and thought that nestedhvm should default to
>>>>>> false, but I would prefer someone more familar with libxl and the idl to
>>>>>> confirm what the default should be.
>>>>> libxl thinks the default is false and will set HVM_PARAM_NESTEDHVM to 0
>>>>> in that case. Is there some way to query the hypervisor for what it
>>>>> thinks the setting is?
>>>> A get hvmparam hypercall will retrieve the value, but it is initialised
>>>> to 0 and only ever set by a set hvmparam hypercall.
>>> Which makes me start suspecting that the guest might be deriving
>>> its information on VMX being available from something other than
>>> CPUID. Of course we ought to confirm that we don't unintentionally
>>> return the VMX flag set (and that the config file doesn't override it
>>> in this way - I think we shouldn't be suppressing user overrides
>>> here, but I didn't go check whether we do).
>> I was also wondering about the behaviour of using vmx instructions in a
>> guest despite vmx not being visible in cpuid...
>>
>> Ian.
>>
>>
> We have found in our situation this is exactly the case. To verify we wrote some
> test code that makes vmx calls without checking cupid. On bare hardware the program
> executes as expected. In a VM on Xen it causes the hypervisor to panic.
>
> From a security standpoint this is very very bad. It might be a good idea to provide either
> a run-time or build-time option to disable nestedhvm. Just turning off the vmx bit is not enough
> as malicious or badly written code can cause a system crash.
>
> For us it looks like we can disable these instructions and avoid the crash.
>
> Jeff.

Hmm - that is very concerning that.

And there does look to be a bug.

Can you try the following patch and see whether it helps?

diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index c9afb56..7b1a349 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -359,7 +359,7 @@ static inline int hvm_event_pending(struct vcpu *v)
 /* These bits in CR4 cannot be set by the guest. */
 #define HVM_CR4_GUEST_RESERVED_BITS(_v)                 \
     (~((unsigned long)                                  \
-       (X86_CR4_VME | X86_CR4_PVI | X86_CR4_TSD |       \
+       (X86_CR4_PVI | X86_CR4_TSD |                     \
         X86_CR4_DE  | X86_CR4_PSE | X86_CR4_PAE |       \
         X86_CR4_MCE | X86_CR4_PGE | X86_CR4_PCE |       \
         X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT |           \

~Andrew

  reply	other threads:[~2013-11-07 15:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 19:54 Intermittent fatal page fault with XEN 4.3.1 (Centos 6.3 DOM0 with linux kernel 3.10.16.) Lars Kurth
2013-11-04 20:00 ` Andrew Cooper
2013-11-05  9:53 ` Ian Campbell
2013-11-05 10:04 ` Jan Beulich
2013-11-05 15:46   ` Lars Kurth
2013-11-05 21:55     ` Jeff_Zimmerman
     [not found]     ` <5E2B3362-4D93-4FEF-987A-E477B0DCEE51@mcafee.com>
2013-11-06 14:09       ` Jan Beulich
2013-11-06 16:05         ` Jeff_Zimmerman
2013-11-06 16:16           ` Jan Beulich
2013-11-06 16:18           ` Ian Campbell
2013-11-06 16:48             ` Jeff_Zimmerman
2013-11-06 16:54               ` Andrew Cooper
2013-11-06 17:06                 ` Ian Campbell
2013-11-06 17:07                   ` Andrew Cooper
2013-11-07  9:10                     ` Jan Beulich
2013-11-07  9:30                       ` Ian Campbell
2013-11-07 15:41                         ` Jeff_Zimmerman
2013-11-07 15:54                           ` Andrew Cooper [this message]
2013-11-07 16:00                             ` Jan Beulich
2013-11-07 16:06                               ` Andrew Cooper
2013-11-07 16:12                                 ` Jeff_Zimmerman
2013-11-07 15:57                           ` Jan Beulich
2013-11-07 16:02                             ` Jeff_Zimmerman
2013-11-07 16:53                               ` Jan Beulich
2013-11-07 17:02                                 ` Andrew Cooper
2013-11-08  7:50                                   ` Jan Beulich
2013-11-07 18:13                                 ` Andrew Cooper
2013-11-07 18:33                                 ` Jeff_Zimmerman
     [not found] <CE9EAEF6.59305%asit.k.mallick@intel.com>
2013-11-05 22:46 ` Jeff_Zimmerman
2013-11-05 23:17   ` Mallick, Asit K
2013-11-06  0:23   ` Andrew Cooper
2013-11-06 10:05     ` Ian Campbell

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=527BB7AA.4080801@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Jeff_Zimmerman@McAfee.com \
    --cc=lars.kurth.xen@gmail.com \
    --cc=lars.kurth@xen.org \
    --cc=xen-devel@lists.xenproject.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.