From patchwork Mon Nov 7 15:38:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 81111 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp1074656qge; Mon, 7 Nov 2016 07:40:18 -0800 (PST) X-Received: by 10.98.74.18 with SMTP id x18mr14567257pfa.58.1478533218001; Mon, 07 Nov 2016 07:40:18 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id 73si22497390pft.153.2016.11.07.07.40.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 07:40:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c3m0o-0007EU-U6; Mon, 07 Nov 2016 15:39:06 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c3m0k-0006uJ-Ub for linux-arm-kernel@lists.infradead.org; Mon, 07 Nov 2016 15:39:04 +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 1315628; Mon, 7 Nov 2016 07:38:40 -0800 (PST) Received: from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 318613F218; Mon, 7 Nov 2016 07:38:38 -0800 (PST) Date: Mon, 7 Nov 2016 15:38:02 +0000 From: Mark Rutland To: Catalin Marinas Subject: Re: [PATCHv4 0/4] WX checking for arm64 Message-ID: <20161107153802.GJ19796@leverpostej> References: <1477585654-8908-1-git-send-email-labbott@redhat.com> <20161030150307.33vc2m7y5y6wzbqc@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161030150307.33vc2m7y5y6wzbqc@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161107_073903_108403_16D53C1A X-CRM114-Status: GOOD ( 16.96 ) X-Spam-Score: -8.3 (--------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-8.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: linux-efi@vger.kernel.org, Kees Cook , AKASHI Takahiro , Matt Fleming , Ard Biesheuvel , Will Deacon , linux-kernel@vger.kernel.org, David Brown , kernel-hardening@lists.openwall.com, Laura Abbott , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Sun, Oct 30, 2016 at 03:03:07PM +0000, Catalin Marinas wrote: > On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote: > > Laura Abbott (4): > > arm64: dump: Make ptdump debugfs a separate option > > arm64: dump: Make the page table dumping seq_file optional > > arm64: dump: Remove max_addr > > arm64: dump: Add checking for writable and exectuable pages > > Queued for 4.10. Thanks. Catalin mentioned to me that he saw some KASAN splats when testing; it looks like need a fixup something like the below. Apologies for not having spotted this when testing! Thanks, Mark. ---->8---- >From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Mon, 7 Nov 2016 15:24:40 +0000 Subject: [PATCH] Fix KASAN splats with DEBUG_WX Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX results in a stream of KASAN splats for stack-out-of-bounds accesses, e.g. -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ================================================================== BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr ffff8009364ebdd0 Read of size 8 by task swapper/0/1 page:ffff7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() page dumped because: kasan: bad access detected CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-00004-g25f7267 #77 Hardware name: ARM Juno development board (r1) (DT) Call trace: [] dump_backtrace+0x0/0x278 [] show_stack+0x14/0x20 [] dump_stack+0xa4/0xc8 [] kasan_report_error+0x4a8/0x4d0 [] kasan_report+0x40/0x48 [] __asan_load8+0x84/0x98 [] note_page+0xd8/0x650 [] walk_pgd.isra.1+0x114/0x220 [] ptdump_check_wx+0xa8/0x118 [] mark_rodata_ro+0x90/0xd0 [] kernel_init+0x28/0x110 [] ret_from_fork+0x10/0x50 Memory state around the buggy address: ffff8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2 ^ ffff8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 ffff8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== ... this happens because note_page assumes that the marker array has at least two elements (the latter of which may be the terminator), but the marker array for ptdump_check_wx only contains one element. Thus we dereference some garbage on the stack when looking at marker[1].start_address. Given we don't need the markers for the WX checks, we could modify note_page to allow for a NULL marker array, but for now it's simpler to add an entry to the ptdump_check_wx marker array, so let's do that. As it's somewhat confusing to have two identical entries, we add an initial entry with a start address of zero. Reported-by: Catalin Marinas Signed-off-by: Mark Rutland --- arch/arm64/mm/dump.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c index ef8aca8..ca74a2a 100644 --- a/arch/arm64/mm/dump.c +++ b/arch/arm64/mm/dump.c @@ -383,6 +383,7 @@ void ptdump_check_wx(void) struct pg_state st = { .seq = NULL, .marker = (struct addr_marker[]) { + { 0, NULL}, { -1, NULL}, }, .check_wx = true,