From patchwork Fri Apr 13 10:02:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Maydell X-Patchwork-Id: 10339743 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 3103A600D0 for ; Fri, 13 Apr 2018 10:25:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1AA972875E for ; Fri, 13 Apr 2018 10:25:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0DA7428760; Fri, 13 Apr 2018 10:25:53 +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=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6B98F2875E for ; Fri, 13 Apr 2018 10:25:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=fKRRiemDi6EY1Z3J2azRa7Zm4OuR0+aoJRjCXEyy5ew=; b=UMb NY6x7rQd12qMJvRcUpB8pxoLjWp++YcHqjVAcXNAc57bSqy6UGARRLlgN1VMF0LTEY7n1GPJUE3bW P8S/rrVZepEgYJSVZmz05zbpiWd5Cir7AxjkQ1qvC7moDcEdOUTJQtEd571c/NO6ge8WUWYVV/uzj swlq2PySyk93sxPGKsClPvZJKAQj6ZGTP5LbOefoaZb8HswPKg9RAEiSyL+RzB0abDjnMVChHfyTc O6Hil3irdxMWyr2lPrsMJmeeh89yBqQJ3iLq8DCKBFWhbzFFcv7pbIUT6fX8mSaoNRqysU2DocWO1 aF4VwWlMuyOw/l5pUZm2XCLTknmOfCQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1f6vtp-0003m9-0V; Fri, 13 Apr 2018 10:25:45 +0000 Received: from orth.archaic.org.uk ([2001:8b0:1d0::2]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f6vtk-0003i9-6i for linux-arm-kernel@lists.infradead.org; Fri, 13 Apr 2018 10:25:42 +0000 Received: from pm215 by orth.archaic.org.uk with local (Exim 4.89) (envelope-from ) id 1f6vWv-0006z9-MZ; Fri, 13 Apr 2018 11:02:05 +0100 From: Peter Maydell To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH] arm64: fault: Don't leak data in ESR context for user fault on kernel VA Date: Fri, 13 Apr 2018 11:02:04 +0100 Message-Id: <20180413100204.9674-1-peter.maydell@linaro.org> X-Mailer: git-send-email 2.16.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180413_032540_423087_51C11FA4 X-CRM114-Status: GOOD ( 17.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Robin Murphy , Will Deacon , Dave Martin , Catalin Marinas , Ard Biesheuvel MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP If userspace faults on a kernel address, handing them the raw ESR value on the sigframe as part of the delivered signal can leak data useful to attackers who are using information about the underlying hardware fault type (e.g. translation vs permission) as a mechanism to defeat KASLR. However there are also legitimate uses for the information provided in the ESR -- notably the GCC and LLVM sanitizers would like to be able to report whether wild pointer accesses by the application are reads or writes (since a wild write is a more serious bug than a wild read), so we don't want to drop the ESR information entirely. For faulting addresses in the kernel, sanitize the ESR. We choose to present userspace with the illusion that there is nothing mapped in the kernel's part of the address space at all, by reporting all faults as level 0 translation faults. These fields are safe to pass through to userspace as they depend only on the instruction that userspace used to provoke the fault: EC IL ISV SAS SSE SRT SF AR CM WNR All the other fields in ESR except DFSC are architecturally zero for an L1 translation fault, so can be zeroed out without confusing userspace. The illusion is not entirely perfect, as there is a tiny wrinkle where we will report an alignment fault that was not due to the memory type (for instance a LDREX to an unaligned address) as a translation fault, whereas if you do this on real unmapped memory the alignment fault takes precedence. This is not likely to trip anybody up in practice, as the only users we know of for the ESR information who care about the behaviour for kernel addresses only really want to know about the WnR bit. Signed-off-by: Peter Maydell --- This RFC patch is an alternative proposal to Will's patch https://patchwork.kernel.org/patch/10258781/ which simply removed the ESR record entirely for kernel addresses. arch/arm64/mm/fault.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index bff11553eb05..933c6d3b906e 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -307,6 +307,57 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr, __show_regs(regs); } + /* + * If the faulting address is in the kernel, we must sanitize the ESR. + * From userspace's point of view, kernel-only mappings don't exist + * at all, so we report them as level 0 translation faults. + * (This is not quite the way that "no mapping there at all" behaves: + * an alignment fault not caused by the memory type would take + * precedence over translation fault for a real access to empty + * space. Unfortunately we can't easily distinguish "alignment fault + * not caused by memory type" from "alignment fault caused by memory + * type", so we ignore this wrinkle and just return the translation + * fault.) + */ + if (addr >= TASK_SIZE) { + switch (ESR_ELx_EC(esr)) { + case ESR_ELx_EC_DABT_CUR: + case ESR_ELx_EC_DABT_LOW: + /* + * These bits provide only information about the + * faulting instruction, which userspace knows already. + * All other bits are architecturally required to be + * zero for faults reported with a DFSCR indicating + * a level 0 translation fault. + */ + esr &= ESR_ELx_EC_MASK | ESR_ELx_IL | ESR_ELx_ISV | + ESR_ELx_SAS | ESR_ELx_SSE | ESR_ELx_SRT_MASK | + ESR_ELx_SF | ESR_ELx_AR | ESR_ELx_CM | + ESR_ELx_WNR; + esr |= ESR_ELx_FSC_FAULT; + break; + case ESR_ELx_EC_IABT_CUR: + case ESR_ELx_EC_IABT_LOW: + /* + * Claim a level 0 translation fault. + * All other bits are architecturally required to be + * zero for faults reported with that DFSC value. + */ + esr &= ESR_ELx_EC_MASK | ESR_ELx_IL; + esr |= ESR_ELx_FSC_FAULT; + break; + default: + /* + * This should never happen (entry.S only brings us + * into this code for insn and data aborts). Fail + * safe by not providing an ESR context record at all. + */ + WARN(1, "ESR 0x%x is not DABT or IABT\n", esr); + esr = 0; + break; + } + } + tsk->thread.fault_address = addr; tsk->thread.fault_code = esr; si.si_signo = sig;