From patchwork Fri May 26 17:03:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 9750865 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6CC0860209 for ; Fri, 26 May 2017 17:05:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 560B9283F9 for ; Fri, 26 May 2017 17:05:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4AA8D28403; Fri, 26 May 2017 17:05:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D34BC283F9 for ; Fri, 26 May 2017 17:05:46 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEIeL-0001n1-HO; Fri, 26 May 2017 17:03:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEIeK-0001mu-Ad for xen-devel@lists.xen.org; Fri, 26 May 2017 17:03:40 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 2D/3D-01735-BEF58295; Fri, 26 May 2017 17:03:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeJIrShJLcpLzFFi42JxWrohUvd1vEa kwafPLBZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8a/4yfZCqZLVUz7/pylgXGiaBcjJ4eEgL/E qoMP2UBsNgF9id0vPjGB2CIC6hKnOy6ydjFycTALTGeUWN+xiBEkISwQKDHl/GYwm0VAVaLp/ ysWEJtXwF1izak1jBBD5STOH//JDGJzCnhIfP7UyQ5iCwHVLLtyghnCVpO41n+JHaJXUOLkzC dgc5gFJCQOvnjBPIGRdxaS1CwkqQWMTKsYNYpTi8pSi3QNDfWSijLTM0pyEzNzdA0NTPVyU4u LE9NTcxKTivWS83M3MQLDhwEIdjCubHc+xCjJwaQkyjt9nXqkEF9SfkplRmJxRnxRaU5q8SFG GQ4OJQneK3EakUKCRanpqRVpmTnAQIZJS3DwKInw3gJJ8xYXJOYWZ6ZDpE4xKkqJ884HSQiAJ DJK8+DaYNFziVFWSpiXEegQIZ6C1KLczBJU+VeM4hyMSsK8B0Cm8GTmlcBNfwW0mAlose85dZ DFJYkIKakGRvvTVqd837B2eF25yZRtYfa8ctFkhi+rkjgSl3z8cNl17W/RYsWd9151C/9ub5P VY/Hcu0go1XXmf77Tk68rTCg+Yxuhoh3NIyZ47obMKUvb1RrP13udDi1XWvzowHnJN78Whzze xyqWukFjwbfvswQWK8ctnbrtxcfihkV3v0zbZG1QtOH7g6dKLMUZiYZazEXFiQDC3nfBmQIAA A== X-Env-Sender: prvs=312dfd0c1=Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1495818216!100286659!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.4.19; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7815 invoked from network); 26 May 2017 17:03:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 26 May 2017 17:03:38 -0000 X-IronPort-AV: E=Sophos;i="5.38,398,1491264000"; d="scan'208";a="425624985" From: Andrew Cooper To: Xen-devel Date: Fri, 26 May 2017 18:03:33 +0100 Message-ID: <1495818213-345-3-git-send-email-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1495818213-345-1-git-send-email-andrew.cooper3@citrix.com> References: <1495818213-345-1-git-send-email-andrew.cooper3@citrix.com> MIME-Version: 1.0 Cc: George Dunlap , Andrew Cooper , Tim Deegan , Jan Beulich Subject: [Xen-devel] [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Despite the claim in the comment (which was based partly on the code already being like that, and mistaken reasoning because of Xen leaking NX into guest context), reality differs. Use of the SMAP feature without NX, or in a 2-level guest, demonstrate an observable difference between reads and instruction fetches, despite PFEC_insn_fetch not being reported in the #PF error code. This demonstrates that instruction fetches are distinguished from data reads even without PFEC_insn_fetch being reported. Alter the pagewalk logic to keep the pagewalk insn_fetch input intact, but only conditionally report insn_fetch in the error code. This logic is more in line with the Intel SDM text: * I/D flag (bit 4). This flag is 1 if (1) the access causing the page-fault exception was an instruction fetch; and (2) either (a) CR4.SMEP = 1; or (b) both (i) CR4.PAE = 1 (either PAE paging or 4-level paging is in use); and (ii) IA32_EFER.NXE = 1. Otherwise, the flag is 0. This flag describes the access causing the page-fault exception, not the access rights specified by paging. and the AMD SDM text: * I/D - Bit 4. If this bit is set to 1, it indicates that the access that caused the page fault was an instruction fetch. Otherwise, this bit is cleared to 0. This bit is only defined if no-execute feature is enabled (EFER.NXE=1 && CR4.PAE=1). Curiously, the AMD manual doesn't mention SMEP despite some Fam16h processors and all Fam17h processors supporting it. Experimentally, it behaves as described by Intel. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap --- xen/arch/x86/mm/guest_walk.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c index 5c6a85b..972364f 100644 --- a/xen/arch/x86/mm/guest_walk.c +++ b/xen/arch/x86/mm/guest_walk.c @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m, ASSERT(!(walk & PFEC_implicit) || !(walk & (PFEC_insn_fetch | PFEC_user_mode))); - /* - * PFEC_insn_fetch is only used as an input to pagetable walking if NX or - * SMEP are enabled. Otherwise, instruction fetches are indistinguishable - * from data reads. - * - * This property can be demonstrated on real hardware by having NX and - * SMEP inactive, but SMAP active, and observing that EFLAGS.AC determines - * whether a pagefault occures for supervisor execution on user mappings. - */ - if ( !(guest_nx_enabled(v) || guest_smep_enabled(v)) ) - walk &= ~PFEC_insn_fetch; - perfc_incr(guest_walk); memset(gw, 0, sizeof(*gw)); gw->va = va; - gw->pfec = walk & (PFEC_insn_fetch | PFEC_user_mode | PFEC_write_access); + gw->pfec = walk & (PFEC_user_mode | PFEC_write_access); + + /* + * PFEC_insn_fetch is only reported if NX or SMEP are enabled. Hardware + * still distingueses instruction fetches during determination of access + * rights. + */ + if ( guest_nx_enabled(v) || guest_smep_enabled(v) ) + gw->pfec |= (walk & PFEC_insn_fetch); #if GUEST_PAGING_LEVELS >= 3 /* PAE or 64... */ #if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */