From patchwork Fri Jul 29 18:53:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 9252765 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 79FC160757 for ; Fri, 29 Jul 2016 18:56:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6A2C42833A for ; Fri, 29 Jul 2016 18:56:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5EB9028402; Fri, 29 Jul 2016 18:56:39 +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 96C692833A for ; Fri, 29 Jul 2016 18:56:38 +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 1bTCuX-000678-DI; Fri, 29 Jul 2016 18:53:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTCuW-000672-6m for xen-devel@lists.xen.org; Fri, 29 Jul 2016 18:53:28 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 56/56-19721-726AB975; Fri, 29 Jul 2016 18:53:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRWlGSWpSXmKPExsVysyfVTVdt2ex wg4mvLCyWfFzM4sDocXT3b6YAxijWzLyk/IoE1ow12zayFpxUqmi59Y2lgfG9ZBcjF4eQwCZG iQcnzjNDOKcZJR4uPwLkcHKwCWhK3Pn8iQnEFhGQlrj2+TIjSBGzwHxGibPb1rGAJIQF4iQ+3 l0PVsQioCpxeMl1sGZeAReJ34c3sIPYEgJyEiePTWadwMi5gJFhFaNGcWpRWWqRrqGxXlJRZn pGSW5iZo6uoYGpXm5qcXFiempOYlKxXnJ+7iZGoM8YgGAH479tnocYJTmYlER5aybNDhfiS8p PqcxILM6ILyrNSS0+xCjDwaEkwcu1BCgnWJSanlqRlpkDDB6YtAQHj5II78TFQGne4oLE3OLM dIjUKUZFKXHeOyB9AiCJjNI8uDZYwF5ilJUS5mUEOkSIpyC1KDezBFX+FaM4B6OSMO8TkCk8m XklcNNfAS1mAlpcHDsDZHFJIkJKqoEx9XlTRMTE3XFcq1JFJkQ6HPQI5Aq0W7kzMJSx6kcvpx NbkttRK5M0lQ/ZuwpnspuyuB7euOr+5NXaQhf/n5Nd1ZFXfqVOXPrrRrPSIu0pmU92z580je/ 6m80BKypP/56/syQv/EQHX+IUm7sn5rzm2eTVal50ZXXbpEVdWoXBb7RmGrKcEpmqxFKckWio xVxUnAgAAMale1MCAAA= X-Env-Sender: julien.grall@arm.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1469818406!51800561!1 X-Originating-IP: [217.140.101.70] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31055 invoked from network); 29 Jul 2016 18:53:26 -0000 Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by server-6.tower-206.messagelabs.com with SMTP; 29 Jul 2016 18:53:26 -0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 64D0D30C; Fri, 29 Jul 2016 11:54:43 -0700 (PDT) Received: from e108454-lin.cambridge.arm.com (e108454-lin.cambridge.arm.com [10.1.218.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 16DEC3F215; Fri, 29 Jul 2016 11:53:23 -0700 (PDT) From: Julien Grall To: xen-devel@lists.xen.org Date: Fri, 29 Jul 2016 19:53:19 +0100 Message-Id: <1469818399-30309-1-git-send-email-julien.grall@arm.com> X-Mailer: git-send-email 1.9.1 Cc: sstabellini@kernel.org, rcojocaru@bitdefender.com, steve.capper@arm.com, Julien Grall , tamas@tklengyel.com, wei.chen@linaro.org Subject: [Xen-devel] [PATCH] xen/arm: p2m: Don't use default access permission when shattering a superpage 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: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP The following message flood the console when memaccess is enabled on various platforms: traps.c:2510:d1v0 HSR=0x9383004f pc=0xffff000008b7d4c4 gva=0xffff000008eeb8e0 gpa=0x0000004903f8e0 This is because a data abort from a guest was received due to a permission fault but memaccess thought there are no permission fault. On ARM, memaccess permissions are stored in a radix tree because there are not enough available bits in the p2m entry to store the access restriction. When memaccess is restricting the access (i.e any other access than p2m_access_rwx), the access will be added in the radix tree using the GFN as a key. This will be done for all 4KB pages. This means that memaccess has to shatter all the superpages in a given region to set the permission on a 4KB granularity. Currently, when a superpage is shattered, the new entries are using the value p2m->default_access which will restrict permission (because memaccess has been enabled). However the radix tree does not yet contain an entry for this GFN. If a guest VCPU is running at the same time and trying to access the modified region, it will result to a stage-2 permission fault. As the radix tree does not yet contain an entry for the GFN, memaccess will deduce that the fault was not valid and a data abort will be injecting to the guest (and crash it). Furthermore, the permission may be restricted outside of the requested region if it is only a subset of a 1GB/2MB superpage. The two issues can be fixed by re-using the permission of the superpage entry and override the necessary fields. This is not a problem because memaccess cannot work on superpage. Lastly, document the code which call mfn_to_p2m_entry when creating a the p2m entry for a table to explain that create the p2m entry to page table to explain that permission are ignored by the hardware (See D4.3.1 in ARM DDI 0487A.j). so the value of the parameter 'access' of mfn_to_p2m_entry does not matter. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- This patch needs to be backported up to Xen 4.6 (first release which introduced memaccess on ARM). This may require few adjustement because the code has changed a bit. Without it, the guest will randomly crash because the permission has been overriden whilst shattering a superpage and before adding the access permission in the radix tree. Also I am wondering if it would be better to pass p2m_access_rwx to mfn_to_p2m_entry when creating a table entry. This would save a couple of instructions. --- xen/arch/arm/p2m.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 40a0b80..d60fbbf 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -434,7 +434,6 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry, p = __map_domain_page(page); if ( splitting ) { - p2m_type_t t = entry->p2m.type; mfn_t mfn = _mfn(entry->p2m.base); int i; @@ -444,15 +443,20 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry, */ for ( i=0 ; i < LPAE_ENTRIES; i++ ) { - pte = mfn_to_p2m_entry(mfn_add(mfn, i << (level_shift - LPAE_SHIFT)), - t, p2m->default_access); + /* + * Use the content of the superpage entry and override + * the necessary fields. So the correct permissions are + * kept. + */ + pte = *entry; + pte.p2m.base = mfn_x(mfn_add(mfn, + i << (level_shift - LPAE_SHIFT))); /* * First and second level super pages set p2m.table = 0, but * third level entries set table = 1. */ - if ( level_shift - LPAE_SHIFT ) - pte.p2m.table = 0; + pte.p2m.table = !(level_shift - LPAE_SHIFT); write_pte(&p[i], pte); } @@ -467,6 +471,10 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry, unmap_domain_page(p); + /* + * The access value does not matter because the hardware will ignore + * the permission fields for table entry. + */ pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid, p2m->default_access);