From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Li, Xin" <xin.li@intel.com>
Cc: "Yang, Wei Y" <wei.y.yang@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir@xen.org>
Subject: Re: [Patch] Disallow SMEP for PV guest
Date: Wed, 1 Jun 2011 13:27:25 -0400 [thread overview]
Message-ID: <20110601172725.GA11261@dumpdata.com> (raw)
In-Reply-To: <FC2FB65B4D919844ADE4BE3C2BB739AD5AB1837C@shsmsx501.ccr.corp.intel.com>
On Thu, Jun 02, 2011 at 12:01:33AM +0800, Li, Xin wrote:
> > >>> This patch disallows SMEP for PV guest.
> > >>
> > >> What are the reasons for it? What do we gain from it?
> > >
> > > X86_64 pv guests runs in ring3, which SMEP doesn't apply to.
> > >
> > > Kernel supports SMEP will set it thru writing to CR4, probably we can silently
> > > ignore such writes from PV guests, but better to not let guest see it.
> >
> > Well, maybe. But if you hide the feature from the guest in CPUID then you
> > should also hide it in CR4, which will involve some messing with
> > real_cr4_to_pv_guest_cr4() and pv_guest_cr4_to_real_cr4(), in a fairly
> > obvious manner. And you should hide it in dom0's CPUID too.
>
> People are very interested in this feature :).
Hmm, can you give more details on what SMEP tries to do? The very interested
sounds like I should be aware of this but .. ah here it is:
SMEP prevents the CPU in kernel-mode to jump to an executable page that does
not have the kernel/system flag set in the pte. This prevents the kernel
from executing user-space code accidentally or maliciously, so it for example
prevents kernel exploits from jumping to specially prepared user-mode shell
code. The violation will cause page fault #PF and will have error code
identical to XD violation.
>
> As it can't apply to ring 3, x86_64 pv guest kernel accessing user code won't
> trigger instruction fetch page fault. thus it makes no sense to use it here.
>
> Definitely we should hide it from dom0 kernel. The change should be in Xen or pvops dom0?
Ugh, if have a patch against the paravirt kernel that would only cover the 3.1 kernel.
So you could still run with the SMEP enabled with the older kernels. Sounds like
a candidate for Xen hypervisor?
next prev parent reply other threads:[~2011-06-01 17:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 14:31 [Patch] Disallow SMEP for PV guest Yang, Wei Y
2011-06-01 14:55 ` Konrad Rzeszutek Wilk
2011-06-01 15:17 ` Li, Xin
2011-06-01 15:36 ` Keir Fraser
2011-06-01 16:01 ` Li, Xin
2011-06-01 17:27 ` Konrad Rzeszutek Wilk [this message]
2011-06-01 20:41 ` Keir Fraser
2011-06-01 15:28 ` Keir Fraser
2011-06-01 15:17 ` Jan Beulich
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=20110601172725.GA11261@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=keir@xen.org \
--cc=wei.y.yang@intel.com \
--cc=xen-devel@lists.xensource.com \
--cc=xin.li@intel.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.