[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DD23CF0.3090108@redhat.com>
Date: Tue, 17 May 2011 12:16:32 +0300
From: Avi Kivity <avi@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Fenghua Yu <fenghua.yu@...el.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Thomas Gleixner <tglx@...utronix.de>,
H Peter Anvin <hpa@...or.com>,
Asit K Mallick <asit.k.mallick@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/4] Enable SMEP CPU Feature
On 05/17/2011 10:03 AM, Ingo Molnar wrote:
> * Fenghua Yu<fenghua.yu@...el.com> wrote:
>
> > From: Fenghua Yu<fenghua.yu@...el.com>
> >
> > Intel new CPU supports SMEP (Supervisor Mode Execution Protection). SMEP
> > prevents kernel from executing code in application. Updated Intel SDM describes
> > this CPU feature. The document will be published soon.
> >
> > Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed,
> > another patch will be pushed for enabling the feature in KVM.
>
> We can do it separately from native kernel support, but i'm sure Avi would
> agree that SMEP support in KVM would be nice!
Definitely.
> (as long as it's configurable as
> well, there might be guest OSs that break if SMEP is enabled, right?)
As mentioned earlier, the simple thing is to expose smep and let the
guest enable it itself.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists