From patchwork Fri Sep 11 14:16:03 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 7162261 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 940D3BEEC1 for ; Fri, 11 Sep 2015 14:36:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9BBC72052C for ; Fri, 11 Sep 2015 14:36:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5154120525 for ; Fri, 11 Sep 2015 14:36:01 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZaPPo-0004ie-1e; Fri, 11 Sep 2015 14:35:00 +0000 Received: from smtp.citrix.com ([66.165.176.89]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZaP8x-0005ol-88 for linux-arm-kernel@lists.infradead.org; Fri, 11 Sep 2015 14:17:36 +0000 X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="299451084" From: Julien Grall To: Subject: [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call Date: Fri, 11 Sep 2015 15:16:03 +0100 Message-ID: <1441980963-9002-1-git-send-email-julien.grall@citrix.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 X-DLP: MIA2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150911_071735_546442_1EFB2E99 X-CRM114-Status: GOOD ( 17.16 ) X-Spam-Score: -6.9 (------) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Russell King , ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, Riku Voipio , linux-kernel@vger.kernel.org, Julien Grall , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When Xen is copyin data to/from the guest it will check if the kernel has the right to do the access. If not, the hypercall will return an error. After the commit a5e090acbf545c0a3b04080f8a488b17ec41fe02 "ARM: software-based priviledged-no-access support", the kernel can't access anymore the user space by default. This will result to fail on every hypercall made by the userspace (i.e via privcmd). We have to enable the userspace access and then restore the correct permission everytime the privmcd is used to made an hypercall. I didn't find generic helpers to do a these operations, so the change is only arm32 specific. Reported-by: Riku Voipio Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Cc: Russell King ARM64 doesn't seem to have priviledge no-access support yet so there is nothing to do for now. I haven't look x86 at all. --- arch/arm/xen/Makefile | 1 + arch/arm/xen/hypercall.S | 4 ++-- arch/arm/xen/privcmd.c | 25 +++++++++++++++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) create mode 100644 arch/arm/xen/privcmd.c diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile index 1296952..d8d088a 100644 --- a/arch/arm/xen/Makefile +++ b/arch/arm/xen/Makefile @@ -1 +1,2 @@ obj-y := enlighten.o hypercall.o grant-table.o p2m.o mm.o +obj-y += privcmd.o diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S index f00e080..56e7181 100644 --- a/arch/arm/xen/hypercall.S +++ b/arch/arm/xen/hypercall.S @@ -91,7 +91,7 @@ HYPERCALL3(vcpu_op); HYPERCALL1(tmem_op); HYPERCALL2(multicall); -ENTRY(privcmd_call) +ENTRY(__privcmd_call) stmdb sp!, {r4} mov r12, r0 mov r0, r1 @@ -102,4 +102,4 @@ ENTRY(privcmd_call) __HVC(XEN_IMM) ldm sp!, {r4} ret lr -ENDPROC(privcmd_call); +ENDPROC(__privcmd_call); diff --git a/arch/arm/xen/privcmd.c b/arch/arm/xen/privcmd.c new file mode 100644 index 0000000..97f502a --- /dev/null +++ b/arch/arm/xen/privcmd.c @@ -0,0 +1,25 @@ +#include +#include + +/* Forward declaration for the assembly function living in hypercall.S */ +long __privcmd_call(unsigned call, unsigned int long a1, + unsigned long a2, unsigned long a3, + unsigned long a4, unsigned long a5); + +long privcmd_call(unsigned call, unsigned int long a1, + unsigned long a2, unsigned long a3, + unsigned long a4, unsigned long a5) +{ + long ret; + /* + * Privcmd calls are issued by the userspace. We need to allow the + * kernel to access the userspace memory before issuing the hypercall. + */ + unsigned int ua_flags = uaccess_save_and_enable(); + + ret = __privcmd_call(call, a1, a2, a3, a4, a5); + + uaccess_restore(ua_flags); + + return ret; +}