From patchwork Fri Oct 9 11:24:18 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King - ARM Linux X-Patchwork-Id: 7361031 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 D8E19BEEA4 for ; Fri, 9 Oct 2015 11:28:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id AE0752089E for ; Fri, 9 Oct 2015 11:28:42 +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 7D2562088E for ; Fri, 9 Oct 2015 11:28:41 +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 1ZkVpB-0006P7-73; Fri, 09 Oct 2015 11:26:57 +0000 Received: from pandora.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZkVp7-0004fh-Qn for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2015 11:26:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=rxA0FM5J2wnkD34Zk0WQTSqzXMlty5dV61LFkh1Iw0o=; b=p9pzZ1c1+/Mc2nnSGgXC/Abb6c6iI2gWM9v4cwmSM43MuCIcHnPZVgFSyDNPImp1uU2C5mhOn/vKabMrhdzCBJSZmm6LxfZEo3poN5rrRZ4awnmAI0JVCRYAUdtJajRLQLE4ca9SpEVUUMg6PD5tGTW+E6mq6KW8zoCnxF8Zz3w=; Received: from n2100.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:40672) by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZkVmf-00059d-T4; Fri, 09 Oct 2015 12:24:22 +0100 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76) (envelope-from ) id 1ZkVmd-0005GY-0L; Fri, 09 Oct 2015 12:24:19 +0100 Date: Fri, 9 Oct 2015 12:24:18 +0100 From: Russell King - ARM Linux To: Will Deacon , Linus Walleij Subject: Re: [PATCH v2 10/10] ARM: software-based priviledged-no-access support Message-ID: <20151009112418.GN32532@n2100.arm.linux.org.uk> References: <20150825154026.GT7557@n2100.arm.linux.org.uk> <20151009105309.GM26278@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151009105309.GM26278@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151009_042654_431285_750E635D X-CRM114-Status: GOOD ( 36.94 ) X-Spam-Score: -4.3 (----) 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: Jeffrey Vander Stoep , Nicolas Schichan , "linux-arm-kernel@lists.infradead.org" , Catalin Marinas 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham 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 On Fri, Oct 09, 2015 at 11:53:09AM +0100, Will Deacon wrote: > On Fri, Oct 09, 2015 at 10:28:14AM +0200, Linus Walleij wrote: > > On Tue, Aug 25, 2015 at 5:42 PM, Russell King > > wrote: > > > > > Provide a software-based implementation of the priviledged no access > > > support found in ARMv8.1. > > > > > > Userspace pages are mapped using a different domain number from the > > > kernel and IO mappings. If we switch the user domain to "no access" > > > when we enter the kernel, we can prevent the kernel from touching > > > userspace. > > > > > > However, the kernel needs to be able to access userspace via the > > > various user accessor functions. With the wrapping in the previous > > > patch, we can temporarily enable access when the kernel needs user > > > access, and re-disable it afterwards. > > > > > > This allows us to trap non-intended accesses to userspace, eg, caused > > > by an inadvertent dereference of the LIST_POISON* values, which, with > > > appropriate user mappings setup, can be made to succeed. This in turn > > > can allow use-after-free bugs to be further exploited than would > > > otherwise be possible. > > > > > > Signed-off-by: Russell King > > > > For some reason this patch explodes on my ARM PB11MPCore, it > > is a weird beast and corner case machine so I guess that is why > > it wasn't noticed. This happens a bit into the boot when freeing > > unused pages: > > > > Freeing unused kernel memory: 2672K (c0448000 - c06e4000) > > Unable to handle kernel paging request at virtual address b6f069f4 > > pgd = c6e58000 > > [b6f069f4] *pgd=76e09831, *pte=77ff759f, *ppte=77ff7e6e > > Internal error: Oops: 17 [#1] SMP ARM > > Modules linked in: > > CPU: 2 PID: 1 Comm: init Not tainted 4.3.0-rc4-00015-gf6702681a0af #48 > > Hardware name: ARM-RealView PB11MPCore > > task: c7827bc0 ti: c782c000 task.ti: c782c000 > > PC is at v6wbi_flush_user_tlb_range+0x28/0x48 > > LR is at on_each_cpu_mask+0x58/0x60 > > pc : [] lr : [] psr: 20000093 > > sp : c782deb8 ip : 00000000 fp : 00000000 > > r10: c6e5adc8 r9 : 00000001 r8 : b6f02000 > > r7 : c7a17180 r6 : c782ded4 r5 : c0015118 r4 : 20000013 > > r3 : 00000002 r2 : 00100075 r1 : b6f02000 r0 : b6f01002 > > Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none > > Control: 00c5787d Table: 76e5800a DAC: 00000051 > > It looks like we're faulting on the TLBI instruction, because it's > targetting a userspace address (r0 == 0xb6f01002) and the DAC prohibits > access to userspace. That's kind'a weird - I'd have expected _cache_ operations to fault, but not TLB operations. From a quick search of the ARM ARM, I can't find anything that says that TLB operations are allowed to fault. > It's weird that this only seems to happen on 11MPCore > though; if this core was one of the guys getting cross-called, then I > could understand the bug, but the lr suggests that CPU 2 is initiating > the flush, so I'd expect the same problem to appear on any ARMv6 part. It sounds to me like a CPU bug, but one which we need to work around. ipi_flush_tlb_range() will be the function concerned, we need to save-and-enable, and then restore the user access state around that call. > Russell, have you tried the s/w PAN stuff on any v6 CPUs? No. I have considered having the Realview EB board as part of the test farm, but as that board is hassle to get going, I deem the hardware to be too unreliable for that. (I reported the problem at the time.) Linus, can you try the patch below to see if it resolves the problem you're seeing please? arch/arm/kernel/smp_tlb.c | 7 +++++++ 1 file changed, 7 insertions(+) Tested-by: Linus Walleij diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c index 2e72be4f623e..7cb079e74010 100644 --- a/arch/arm/kernel/smp_tlb.c +++ b/arch/arm/kernel/smp_tlb.c @@ -9,6 +9,7 @@ */ #include #include +#include #include #include @@ -40,8 +41,11 @@ static inline void ipi_flush_tlb_mm(void *arg) static inline void ipi_flush_tlb_page(void *arg) { struct tlb_args *ta = (struct tlb_args *)arg; + unsigned int __ua_flags = uaccess_save_and_enable(); local_flush_tlb_page(ta->ta_vma, ta->ta_start); + + uaccess_restore(__ua_flags); } static inline void ipi_flush_tlb_kernel_page(void *arg) @@ -54,8 +58,11 @@ static inline void ipi_flush_tlb_kernel_page(void *arg) static inline void ipi_flush_tlb_range(void *arg) { struct tlb_args *ta = (struct tlb_args *)arg; + unsigned int __ua_flags = uaccess_save_and_enable(); local_flush_tlb_range(ta->ta_vma, ta->ta_start, ta->ta_end); + + uaccess_restore(__ua_flags); } static inline void ipi_flush_tlb_kernel_range(void *arg)