From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754671AbcAHKZ1 (ORCPT ); Fri, 8 Jan 2016 05:25:27 -0500 Received: from mail-io0-f181.google.com ([209.85.223.181]:36038 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754486AbcAHKZQ (ORCPT ); Fri, 8 Jan 2016 05:25:16 -0500 MIME-Version: 1.0 In-Reply-To: <568F8C9E.1010608@arm.com> References: <1451489172-17420-1-git-send-email-ard.biesheuvel@linaro.org> <1451489172-17420-13-git-send-email-ard.biesheuvel@linaro.org> <568F8C9E.1010608@arm.com> Date: Fri, 8 Jan 2016 11:25:14 +0100 Message-ID: Subject: Re: [PATCH v2 12/13] arm64: add support for relocatable kernel From: Ard Biesheuvel To: James Morse Cc: "linux-arm-kernel@lists.infradead.org" , kernel-hardening@lists.openwall.com, Will Deacon , Catalin Marinas , Mark Rutland , Leif Lindholm , Kees Cook , "linux-kernel@vger.kernel.org" , Stuart Yoder , Sharma Bhupesh , Arnd Bergmann , Marc Zyngier , Christoffer Dall Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8 January 2016 at 11:17, James Morse wrote: > Hi Ard! > > On 30/12/15 15:26, Ard Biesheuvel wrote: >> This adds support for runtime relocation of the kernel Image, by >> building it as a PIE (ET_DYN) executable and applying the dynamic >> relocations in the early boot code. >> >> Signed-off-by: Ard Biesheuvel >> --- > >> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S >> index 01a33e42ed70..ab582ee58b58 100644 >> --- a/arch/arm64/kernel/head.S >> +++ b/arch/arm64/kernel/head.S >> @@ -243,6 +253,16 @@ ENDPROC(stext) >> preserve_boot_args: >> mov x21, x0 // x21=FDT >> >> +#ifdef CONFIG_ARM64_RELOCATABLE_KERNEL >> + /* >> + * Mask off the bits of the random value supplied in x1 so it can serve >> + * as a KASLR displacement value which will move the kernel image to a >> + * random offset in the lower half of the VMALLOC area. >> + */ >> + mov x23, #(1 << (VA_BITS - 2)) - 1 >> + and x23, x23, x1, lsl #SWAPPER_BLOCK_SHIFT >> +#endif > > I've managed to make this fail to boot by providing a seed that caused > the kernel to overlap a 1G boundary on a 4K system. > Ah, yes. Thanks for spotting that. > (It looks like your v3 may have the same issue - but I haven't tested it.) > > Yes, it does. It probably makes sense to sacrifice some entropy bits and simply round up the kaslr offset to a log2 upper bound of the kernel Image size, rather than hacking up some logic in assembly to test whether we are crossing a PMD/PUD boundary >> + >> adr_l x0, boot_args // record the contents of >> stp x21, x1, [x0] // x0 .. x3 at kernel entry >> stp x2, x3, [x0, #16] > > > Thanks! > > James > From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Fri, 8 Jan 2016 11:25:14 +0100 Subject: [PATCH v2 12/13] arm64: add support for relocatable kernel In-Reply-To: <568F8C9E.1010608@arm.com> References: <1451489172-17420-1-git-send-email-ard.biesheuvel@linaro.org> <1451489172-17420-13-git-send-email-ard.biesheuvel@linaro.org> <568F8C9E.1010608@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 8 January 2016 at 11:17, James Morse wrote: > Hi Ard! > > On 30/12/15 15:26, Ard Biesheuvel wrote: >> This adds support for runtime relocation of the kernel Image, by >> building it as a PIE (ET_DYN) executable and applying the dynamic >> relocations in the early boot code. >> >> Signed-off-by: Ard Biesheuvel >> --- > >> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S >> index 01a33e42ed70..ab582ee58b58 100644 >> --- a/arch/arm64/kernel/head.S >> +++ b/arch/arm64/kernel/head.S >> @@ -243,6 +253,16 @@ ENDPROC(stext) >> preserve_boot_args: >> mov x21, x0 // x21=FDT >> >> +#ifdef CONFIG_ARM64_RELOCATABLE_KERNEL >> + /* >> + * Mask off the bits of the random value supplied in x1 so it can serve >> + * as a KASLR displacement value which will move the kernel image to a >> + * random offset in the lower half of the VMALLOC area. >> + */ >> + mov x23, #(1 << (VA_BITS - 2)) - 1 >> + and x23, x23, x1, lsl #SWAPPER_BLOCK_SHIFT >> +#endif > > I've managed to make this fail to boot by providing a seed that caused > the kernel to overlap a 1G boundary on a 4K system. > Ah, yes. Thanks for spotting that. > (It looks like your v3 may have the same issue - but I haven't tested it.) > > Yes, it does. It probably makes sense to sacrifice some entropy bits and simply round up the kaslr offset to a log2 upper bound of the kernel Image size, rather than hacking up some logic in assembly to test whether we are crossing a PMD/PUD boundary >> + >> adr_l x0, boot_args // record the contents of >> stp x21, x1, [x0] // x0 .. x3 at kernel entry >> stp x2, x3, [x0, #16] > > > Thanks! > > James > From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: <568F8C9E.1010608@arm.com> References: <1451489172-17420-1-git-send-email-ard.biesheuvel@linaro.org> <1451489172-17420-13-git-send-email-ard.biesheuvel@linaro.org> <568F8C9E.1010608@arm.com> Date: Fri, 8 Jan 2016 11:25:14 +0100 Message-ID: From: Ard Biesheuvel Content-Type: text/plain; charset=UTF-8 Subject: [kernel-hardening] Re: [PATCH v2 12/13] arm64: add support for relocatable kernel To: James Morse Cc: "linux-arm-kernel@lists.infradead.org" , kernel-hardening@lists.openwall.com, Will Deacon , Catalin Marinas , Mark Rutland , Leif Lindholm , Kees Cook , "linux-kernel@vger.kernel.org" , Stuart Yoder , Sharma Bhupesh , Arnd Bergmann , Marc Zyngier , Christoffer Dall List-ID: On 8 January 2016 at 11:17, James Morse wrote: > Hi Ard! > > On 30/12/15 15:26, Ard Biesheuvel wrote: >> This adds support for runtime relocation of the kernel Image, by >> building it as a PIE (ET_DYN) executable and applying the dynamic >> relocations in the early boot code. >> >> Signed-off-by: Ard Biesheuvel >> --- > >> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S >> index 01a33e42ed70..ab582ee58b58 100644 >> --- a/arch/arm64/kernel/head.S >> +++ b/arch/arm64/kernel/head.S >> @@ -243,6 +253,16 @@ ENDPROC(stext) >> preserve_boot_args: >> mov x21, x0 // x21=FDT >> >> +#ifdef CONFIG_ARM64_RELOCATABLE_KERNEL >> + /* >> + * Mask off the bits of the random value supplied in x1 so it can serve >> + * as a KASLR displacement value which will move the kernel image to a >> + * random offset in the lower half of the VMALLOC area. >> + */ >> + mov x23, #(1 << (VA_BITS - 2)) - 1 >> + and x23, x23, x1, lsl #SWAPPER_BLOCK_SHIFT >> +#endif > > I've managed to make this fail to boot by providing a seed that caused > the kernel to overlap a 1G boundary on a 4K system. > Ah, yes. Thanks for spotting that. > (It looks like your v3 may have the same issue - but I haven't tested it.) > > Yes, it does. It probably makes sense to sacrifice some entropy bits and simply round up the kaslr offset to a log2 upper bound of the kernel Image size, rather than hacking up some logic in assembly to test whether we are crossing a PMD/PUD boundary >> + >> adr_l x0, boot_args // record the contents of >> stp x21, x1, [x0] // x0 .. x3 at kernel entry >> stp x2, x3, [x0, #16] > > > Thanks! > > James >