From patchwork Wed Sep 6 16:35:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 9941105 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 5AD5060216 for ; Wed, 6 Sep 2017 16:35:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D24B28BFF for ; Wed, 6 Sep 2017 16:35:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 41A0A28C0B; Wed, 6 Sep 2017 16:35: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=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id AED2E28BFF for ; Wed, 6 Sep 2017 16:35:51 +0000 (UTC) Received: (qmail 7590 invoked by uid 550); 6 Sep 2017 16:35:49 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 7554 invoked from network); 6 Sep 2017 16:35:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gkk8sdnVMHUXTS4IflkCdfJ1HAQz8pT0tpBffdW+w2I=; b=NqfzcjSxdwwxRNDNJr+Rq3yhNPREYFDlF7oPC3LH3L6bqVWV8FsW0mtQvN7bgoydo0 AmCzIoDS1ZT0zikWC9g6IZMNHJ/XVTWKDIXwEXcu1tZUw/UYXSXnTy2sOoCfTUL3JFyD 0qyMrqeDKqbxZwdDXRTJ/F4Dsh6NS+GcrNDgg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gkk8sdnVMHUXTS4IflkCdfJ1HAQz8pT0tpBffdW+w2I=; b=LptRatmi0G5fTGPCnz2RBfuaJyWkUlw3aDaE9vi6Jqm7Skjs7MxU7hqhi1hH0kMs4v D06zo7e1V6VN6SyQHW1/wrSlNlYtQboOkvthBD2p6mDaOQSYeuBI2UFVx1rBSWHTU0iX lOe8A189FJdHOytvSSKNo8Fe4ZLQTLT+6Wl96xfVpw8Ni7sVZqjcRuSDMax7acoBXz1A 5bAHedny7W2vEGvMchSLyZ/x3WpbG0aAAytpchJ98uJGH5rFHPR5SVnGdv46/19YA28T pHqiQgdrjj0RJGv+Uix8O855IIxCkmECuPtHCEeqWtTlUcGsj76TNGVzkmIOqtICVitW Cw7Q== X-Gm-Message-State: AHPjjUib/XqJvtwwIuSx3GcEvUZl1BKz6HqNIND5DHWUsWZfeylZOQdQ Xeh814Pc6nX8ww3i/X1RyeOBdL5IqRz+ X-Google-Smtp-Source: AOwi7QBtL4C10yYNTYkriXZmM4g+OrKjxlleg6Mn/ZaCp8o77Yp67B2Rr/guJjiH8KRYmjerWxxWSejjoaD+mL+VfCI= X-Received: by 10.107.46.20 with SMTP id i20mr3381700ioo.192.1504715736996; Wed, 06 Sep 2017 09:35:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170906163100.GJ5024@atomide.com> References: <20170903120757.14968-1-ard.biesheuvel@linaro.org> <20170905164547.GA5024@atomide.com> <20170905193754.GD5024@atomide.com> <20170905212742.GG5024@atomide.com> <20170906162222.GI5024@atomide.com> <20170906163100.GJ5024@atomide.com> From: Ard Biesheuvel Date: Wed, 6 Sep 2017 17:35:36 +0100 Message-ID: To: Tony Lindgren Cc: "linux-arm-kernel@lists.infradead.org" , Kernel Hardening , Arnd Bergmann , Nicolas Pitre , Russell King , Kees Cook , Thomas Garnier , Marc Zyngier , Mark Rutland , Matt Fleming , Dave Martin Subject: [kernel-hardening] Re: [PATCH v2 00/29] implement KASLR for ARM X-Virus-Scanned: ClamAV using ClamSMTP On 6 September 2017 at 17:31, Tony Lindgren wrote: > * Ard Biesheuvel [170906 09:26]: >> On 6 September 2017 at 17:22, Tony Lindgren wrote: >> > Sure was not able to reproduce it so far on BBB. But here's >> > failed boot output from logicpd-torpedo-37xx-devkit. Will >> > try some more booting on BBB too. > ... >> > 8< ------------------- >> > Kernel image @ 0x81000000 [ 0x000000 - 0x426810 ] >> > ## Flattened Device Tree blob at 84000000 >> > Booting using the fdt blob at 0x84000000 >> > Loading Device Tree to 86feb000, end 86fff2d5 ... OK >> > >> > Starting kernel ... >> > >> > regions.image_size:00e00000 >> > regions.pa_start:80000000 >> > regions.pa_end:88000000 >> > regions.zimage_start:81000000 >> > regions.zimage_size:00437830 >> > regions.dtb_start:86feb000 >> > regions.dtb_size:00012000 >> > regions.initrd_start:00000000 >> > regions.initrd_size:00000000 >> > num:0000002f >> > num:00000029 >> > *kaslr_offset:07400000 >> > Uncompressing Linux... >> >> Is that all? Does it hang while decompressing the kernel? > > Yeah so it seems. If we had uncompress overwriting something > because of the increase in size it should happen on every > boot though, not once every five boots or so. > Turns out I am calculating the top of DRAM incorrectly for boards where less memory is present than the size of the lowmem region. Could you try this please? (Apologies for the whitespace) regions.dtb_start = (u32)fdt; @@ -391,7 +390,8 @@ u32 kaslr_early_init(u32 *kaslr_offset, u32 image_base, u32 image_size, } /* check the memory nodes for the size of the lowmem region */ - regions.pa_end = min(regions.pa_end, get_memory_end(fdt)); + regions.pa_end = min(regions.pa_end, get_memory_end(fdt)) - + regions.image_size; puthex32(regions.image_size); puthex32(regions.pa_start); diff --git a/arch/arm/boot/compressed/kaslr.c b/arch/arm/boot/compressed/kaslr.c index d43c0be9b47b..e9c86809c857 100644 --- a/arch/arm/boot/compressed/kaslr.c +++ b/arch/arm/boot/compressed/kaslr.c @@ -339,8 +339,7 @@ u32 kaslr_early_init(u32 *kaslr_offset, u32 image_base, u32 image_size, regions.image_size = round_up(image_size, SZ_2M); regions.pa_start = round_down(image_base, SZ_128M); - regions.pa_end = lowmem_top - PAGE_OFFSET + regions.pa_start - - regions.image_size; + regions.pa_end = lowmem_top - PAGE_OFFSET + regions.pa_start; regions.zimage_start = zimage_start; regions.zimage_size = zimage_end - zimage_start;