From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [Patch] Enable SMEP CPU feature support for XEN itself Date: Wed, 01 Jun 2011 21:43:42 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Li, Xin" , "Yang, Wei Y" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 01/06/2011 17:15, "Li, Xin" wrote: >>> This patch enables SMEP in Xen to protect Xen hypervisor from executing pv >>> guest code, >> >> Well not really. In the case that *Xen* execution triggers SMEP, you should >> crash. > > You don't expect Xen can trigger SMEP? somehow I agree, but in case there is > any null pointer in Xen, an evil pv guest can easily get control of the > system. Of course. I don't disagree there can be bugs in Xen. :-) >> >>> and kills a pv guest triggering SMEP fault. >> >> Should only occur when the guest kernel triggers the SMEP. > > According to code base size, it's much easier for malicious applications to > explore > security holes in kernel. But unluckily SMEP doesn't apply to the ring 3 > where > x86_64 pv kernel runs on. It's wiser to use HVM :) Yep, but 32-bit guests can still benefit. >> Basically you need to pull your check out of spurious_page_fault() and into >> the two callers, because their responses should differ (one crashes the >> guest, the other crashes the hypervisor). >> Please define an enumeration for the return codes from spurious_pf, rather >> than using magic numbers. > > Will do. Thanks. - Keir