From patchwork Fri Aug 18 15:35:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 9909441 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 1CC9660382 for ; Fri, 18 Aug 2017 15:37:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 07FA928CE6 for ; Fri, 18 Aug 2017 15:37:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F0A5A28CFB; Fri, 18 Aug 2017 15:37:22 +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.6 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.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 0E54A28CE6 for ; Fri, 18 Aug 2017 15:37:22 +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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZY91UK6LOcti5WNgVscSimXjrMaxAPM762WZq87HHIw=; b=GERDIucsb311MF g579lwUUtv7xFvgFpcKZzKPDGGz74yZ5fbykN7tuoOt4jogTcv4v7dp10gAjnxEd6XI7cBcgJiwXJ ukbmr3lyZWZop7VJ2tLM62FZHHH6gf11QRhO2SLnikuN3XfnBgv+1DoauSuT6f5cBym4xPWzrR2n5 B5Spyo0Jz6zZoJuKkOXxRkbYtGjMGslmX4hPvAG6EdZqSvVqXwNhc5nNCRCrGzpIupI974HOgu/dX 9dYT2UqxAizxG7ff31Wlni7MhiScOEvLzC5gBeZIi9IZpxvlvaLG3bKTvnISoWYC/APIdTwI4mpo1 kjAXskSfMI8fgNzOxoOw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dijKn-0002Zh-QP; Fri, 18 Aug 2017 15:37:17 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dijKc-0002Es-FX for linux-arm-kernel@lists.infradead.org; Fri, 18 Aug 2017 15:37:15 +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 2D8372B; Fri, 18 Aug 2017 08:36:46 -0700 (PDT) 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 1D68E3F540; Fri, 18 Aug 2017 08:36:44 -0700 (PDT) Date: Fri, 18 Aug 2017 16:35:31 +0100 From: Mark Rutland To: Ard Biesheuvel Subject: Re: [PATCH] arm64: kaslr: Adjust the offset to avoid Image across alignment boundary Message-ID: <20170818153531.GA22970@leverpostej> References: <20170818150435.35224-1-catalin.marinas@arm.com> <20170818151920.jpugpcgwiavgwgaf@armageddon.cambridge.arm.com> <20170818152257.dbllbeuxwm5nugno@armageddon.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20170818_083706_544714_C052CE7F X-CRM114-Status: GOOD ( 26.13 ) 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: Catalin Marinas , Will Deacon , Neeraj Upadhyay , "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-Virus-Scanned: ClamAV using ClamSMTP On Fri, Aug 18, 2017 at 04:24:46PM +0100, Ard Biesheuvel wrote: > On 18 August 2017 at 16:22, Catalin Marinas wrote: > > On Fri, Aug 18, 2017 at 04:20:16PM +0100, Ard Biesheuvel wrote: > >> On 18 August 2017 at 16:19, Catalin Marinas wrote: > >> > On Fri, Aug 18, 2017 at 04:04:34PM +0100, Catalin Marinas wrote: > >> >> With 16KB pages and a kernel Image larger than 16MB, the current > >> >> kaslr_early_init() logic for avoiding mappings across swapper table > >> >> boundaries fails since increasing the offset by kimg_sz just moves the > >> >> problem to the next boundary. > >> >> > >> >> This patch decreases the offset by the boundary overflow amount, with > >> >> slight risk of reduced entropy as the kernel is more likely to be found > >> >> at kimg_sz below a swapper table boundary. > >> >> > >> >> Trying-to-fix: afd0e5a87670 ("arm64: kaslr: Fix up the kernel image alignment") > >> >> Cc: Ard Biesheuvel > >> >> Cc: Mark Rutland > >> >> Cc: Will Deacon > >> >> Cc: Neeraj Upadhyay > >> >> Signed-off-by: Catalin Marinas > >> >> --- > >> >> > >> >> While preparing this email, I noticed that the kernel eventually failed > >> >> to boot, though after a lot more reboot iterations. Mark Rutland also > >> >> managed to make the KASLR kernel fail to boot with 64K pages which > >> >> wouldn't be explained by this patch. > >> >> > >> >> So, any suggestions are welcome. My testing method, qemu starting a > >> >> guest in a loop with virtio-rng-pci. > >> > > >> > Apparently, the booting gets much more stable if I disable the physical > >> > relocation in arm64-stub.c (but keep the virtual one with the fix in > >> > this patch). So I guess we are chasing two different issues. > >> > >> So this is using QEMU with 16k pages support? > > > > Qemu running on a ThunderX, so native KVM support. > > > > Ah ok. I did not realize QEMU supports 16 KB pages in that case. Nice! > > However, that makes it rather difficult to reproduce on my side. FWIW, I was testing with 64K pages, under QEMU+KVM on a SoftIrorn OverDrive 1000 (i.e. a 4-core A57 system). I'd hacked early_kaslr_init() so that I could override the seed on the command line. I accidentally blatted that hack, but hopefully the below is equivalent. I had a script that iterated the seed in 2M increments, launch a VM for each seed. The fileststem was configured to power down immediately once it reached userspace. I found that it hung with seed value: 0x0000000016c00000, which would generate an offset of 0x17e00000. I tried nearby seeds, which worked: seed offset 0x0000000016a00000 0x16a00000 worked 0x0000000016c00000 0x17e00000 failed 0x0000000016e00000 0x18000000 worked ... but I assume that failing values are dependent on the kernel Image layout. Thanks, Mark. ---->8---- t a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c index a9710ef..df50442 100644 --- a/arch/arm64/kernel/kaslr.c +++ b/arch/arm64/kernel/kaslr.c @@ -102,8 +102,8 @@ u64 __init kaslr_early_init(u64 dt_phys, u64 modulo_offset) * Retrieve (and wipe) the seed from the FDT */ seed = get_kaslr_seed(fdt); - if (!seed) - return 0; + //if (!seed) + // return 0; /* * Check if 'nokaslr' appears on the command line, and @@ -114,6 +114,12 @@ u64 __init kaslr_early_init(u64 dt_phys, u64 modulo_offset) if (str == cmdline || (str > cmdline && *(str - 1) == ' ')) return 0; + str = strstr(cmdline, "kaslr_seed=") + if (str) { + str += strlen("kaslr_seed="); + seed = simple_strtoull(str, NULL, 16); + } + /* * OK, so we are proceeding with KASLR enabled. Calculate a suitable * kernel image offset from the seed. Let's place the kernel in the