From patchwork Tue May 22 16:11:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Maydell X-Patchwork-Id: 10419099 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 26463600CC for ; Tue, 22 May 2018 16:23:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 149B9284D4 for ; Tue, 22 May 2018 16:23:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0705228F72; Tue, 22 May 2018 16:23:41 +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 538B5284D4 for ; Tue, 22 May 2018 16:23:40 +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=OmnNwRrPfgUnJY97ikflq7hVqgRc6QcG/nb8Ia3rHvE=; b=Lwr /UtV/igm8h2m9f8QN3Gk8faO9VAlCmS2tOCwwV+iKKhdeAbC0wPaFPABgtimmoN7URy84iA4CC7Au 9KOlopqNYFHOh/Tb48pCVSZBEHAH2KrzrO8XmkXJ+hGczd2J7fxknlaFEGvQkgX5FkW3wompcAT9t YyrOACZeGOtUJYAJsA4oqc+HMvpea6eI7Nwj220x5M1KTIh4PM7fNNvj4FOzlRRgKDkTwriTTg4aP h/OV4hI5+Mat4ExonW09LJC2pjeqb7OKiFdx+7JMGvxileduHUwpffV85HaF10WGW7lo4pF/ZFDWp 7/e+bzjeiHmqFkSxlhS+88FtRjYC1iA==; 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 1fLA4V-0007s0-CZ; Tue, 22 May 2018 16:23:35 +0000 Received: from casper.infradead.org ([85.118.1.10]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fLA2r-0006Z2-Az for linux-arm-kernel@bombadil.infradead.org; Tue, 22 May 2018 16:21:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PRwLLipEykUikF3jTykJEuxAOOA5XzST4m9gESvq30Q=; b=wVKYNeL+27mqaNmw7mq5b0ZTT 9MukMls1J0hdZ8zCMWMQA/O+Pp1jc8NYp5+9wq+GxX3aKfDDDbRP3UgpNFwQg2py/DPA4JxtYuogR iL+CHDLGJf8ziCau3eQrlUqw8LFdxBsR+sqq0OckLP3i39NOucm3B/PjvJbKGQAFkCsjwEhoaYB2G GDG8YUBxh5+JC7hDbKz1FBLe4irPRTycoMlDXod/GtIrL3okFCpLy5tXbjqtV+ZaHdnz4pcXIGYFO WMF9Qxu27Wxvwn2XkWK5TSwu2fAwk35gOHStKgQHg/M+UVtWXkZkvnH3Gz5CHaikWq3vskm4fh0XL BPdmDZmxg==; Received: from orth.archaic.org.uk ([2001:8b0:1d0::2]) by casper.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fL9sx-0002XH-6U for linux-arm-kernel@lists.infradead.org; Tue, 22 May 2018 16:11:43 +0000 Received: from pm215 by orth.archaic.org.uk with local (Exim 4.89) (envelope-from ) id 1fL9sf-00014C-Lp; Tue, 22 May 2018 17:11:21 +0100 From: Peter Maydell To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3] arm64: fault: Don't leak data in ESR context for user fault on kernel VA Date: Tue, 22 May 2018 17:11:20 +0100 Message-Id: <20180522161120.12798-1-peter.maydell@linaro.org> X-Mailer: git-send-email 2.17.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180522_171139_986993_7EEE8A67 X-CRM114-Status: GOOD ( 22.76 ) 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: Will Deacon , Ard Biesheuvel , Robin Murphy , Dave Martin , Catalin Marinas 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 use this 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 taken to EL1. 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 (always) ISV CM WNR (for all data aborts) All the other fields in ESR except DFSC are architecturally RES0 for an L0 translation fault taken to EL1, 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 Reviewed-by: Dave Martin --- This 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. Changes v1->v2: * rebased on master * commit message tweak * DABT_CUR and IABT_CUR moved to "can't happen" default case * explicitly clear the bits which are RES0 if ISV == 0 * comment text tweaks Changes v2->v3: * remove the support for reporting ESRs with ISV == 1 (this can't happen, and we probably don't want to tell userspace that the exception was taken to EL2 if in some hypothetical future that becomes possible) * rebased on 4.17-rc6 --- 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 4165485e8b6e..2af3dd89bcdb 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -293,6 +293,57 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr, static void __do_user_fault(struct siginfo *info, unsigned int esr) { current->thread.fault_address = (unsigned long)info->si_addr; + + /* + * 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 (current->thread.fault_address >= TASK_SIZE) { + switch (ESR_ELx_EC(esr)) { + case ESR_ELx_EC_DABT_LOW: + /* + * These bits provide only information about the + * faulting instruction, which userspace knows already. + * We explicitly clear bits which are architecturally + * RES0 in case they are given meanings in future. + * We always report the ESR as if the fault was taken + * to EL1 and so ISV and the bits in ISS[23:14] are + * clear. (In fact it always will be a fault to EL1.) + */ + esr &= ESR_ELx_EC_MASK | ESR_ELx_IL | + ESR_ELx_CM | ESR_ELx_WNR; + esr |= ESR_ELx_FSC_FAULT; + break; + case ESR_ELx_EC_IABT_LOW: + /* + * Claim a level 0 translation fault. + * All other bits are architecturally RES0 for faults + * reported with that DFSC value, so we clear them. + */ + 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 from a lower + * exception level). Fail safe by not providing an ESR + * context record at all. + */ + WARN(1, "ESR 0x%x is not DABT or IABT from EL0\n", esr); + esr = 0; + break; + } + } + current->thread.fault_code = esr; arm64_force_sig_info(info, esr_to_fault_info(esr)->name, current); }