|
Message-ID: <CAKv+Gu_eT_eK9Tj4JvWSsK+iW9juGG6xYDO15umu6jBkoun8ew@mail.gmail.com> Date: Tue, 5 Sep 2017 17:48:58 +0100 From: Ard Biesheuvel <ard.biesheuvel@...aro.org> To: Tony Lindgren <tony@...mide.com> Cc: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Arnd Bergmann <arnd@...db.de>, Nicolas Pitre <nico@...aro.org>, Russell King <linux@...linux.org.uk>, Kees Cook <keescook@...omium.org>, Thomas Garnier <thgarnie@...gle.com>, Marc Zyngier <marc.zyngier@....com>, Mark Rutland <mark.rutland@....com>, Matt Fleming <matt@...eblueprint.co.uk>, Dave Martin <dave.martin@....com> Subject: Re: [PATCH v2 00/29] implement KASLR for ARM On 5 September 2017 at 17:45, Tony Lindgren <tony@...mide.com> wrote: > Hi, > > * Ard Biesheuvel <ard.biesheuvel@...aro.org> [170903 05:08]: >> This series implements randomization of the placement of the core ARM kernel >> inside the lowmem region. It consists of the following parts: >> >> - changes that allow us to build vmlinux as a PIE executable which retains >> the metadata required to fix up all absolute symbol references at runtime >> - changes that eliminate absolute references from low-level code that may >> execute with the MMU off: this removes the need to perform explicit cache >> maintenance after the absolute references have been fixed up at runtime with >> the caches enabled >> - changes to the core kernel startup code to take the physical offset into >> account when creating the virtual mapping (the pa-to-va mapping remains >> unchanged) >> - changes to the decompressor to collect some pseudo-entropy, and randomize >> the physical offset of the decompressed kernel, taking placement of DTB, >> initrd and reserved regions into account >> - changes to the UEFI stub code to choose the KASLR offset and communicate >> it to the decompressor >> >> To test these changes, boot a multi_v7_defconfig+CONFIG_RANDOMIZE_BASE=y > > I gave a quick try using your arm-kaslr-v3 branch, hopefully that's > the right one. > > The good news is that now omap3 boots with omap2plus_defconfig with > and without CONFIG_RANDOMIZE_BASE=y and I did not see any compiler > errors with my gcc 6.2.0 like earlier :) > Good! Thanks a lot for taking the time to test this stuff. > I did see boot attempts fail with randomize enable where no output > was produced. It seems this is happening for me maybe 1 out of 5 boots. > Enabling DEBUG_LL did not show anything either. > Yes. I am looking into a couple of kernelci boot reports that look suspicious, but it is rather difficult to reproduce, for obvious reasons :-) Which hardware are you testing this on? > Then loading modules with CONFIG_RANDOMIZE_BASE=y seems to fail with: > > $ sudo modprobe rtc-twl > rtc_twl: disagrees about version of symbol module_layout > modprobe: ERROR: could not insert 'rtc_twl': Exec format error > Is this with CONFIG_MODVERSIONS enabled? Thanks, Ard.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.