Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753123AbbBZG3c (ORCPT ); Thu, 26 Feb 2015 01:29:32 -0500 Received: from mail-ig0-f176.google.com ([209.85.213.176]:35175 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752711AbbBZG3a (ORCPT ); Thu, 26 Feb 2015 01:29:30 -0500 MIME-Version: 1.0 In-Reply-To: <20150120130457.GG2461@dhcp-16-105.nay.redhat.com> References: <20150116005146.GA4212@www.outflux.net> <20150120130457.GG2461@dhcp-16-105.nay.redhat.com> Date: Thu, 26 Feb 2015 07:29:30 +0100 Message-ID: Subject: Re: [PATCH] x86, boot: skip relocs when load address unchanged From: MegaBrutal To: Baoquan He Cc: Kees Cook , Linux kernel , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , Vivek Goyal , Jan Beulich , Junjie Mao , Andi Kleen , "Thomas D." Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4027 Lines: 97 Thanks for this patch, and good to see it in mainline! This actually fixes the problem I reported here: https://lkml.org/lkml/2014/12/1/15 I wish it to be backported into the Ubuntu Utopic kernel asap. > This patch works for me. And good to see it's being merged. About the > patch log, I would say relocations do unexpected things when the kernel > is above 1G since randomization is done from 16M to 1G, namely > CONFIG_RANDOMIZE_BASE_MAX_OFFSET. So above 1G kernel text mapping will > step into kernel module mapping region. I'm just speculating, but is it the reason why I only get problems when I boot with kexec? Maybe it's only then when the kernel gets above 1G. Otherwise, the kernels boot properly when they are booted from GRUB. 2015-01-20 14:04 GMT+01:00 Baoquan He : > > On 01/15/15 at 04:51pm, Kees Cook wrote: > > On 64-bit, relocation is not required unless the load address gets > > changed. Without this, relocations do unexpected things when the kernel > > is above 4G. > > This patch works for me. And good to see it's being merged. About the > patch log, I would say relocations do unexpected things when the kernel > is above 1G since randomization is done from 16M to 1G, namely > CONFIG_RANDOMIZE_BASE_MAX_OFFSET. So above 1G kernel text mapping will > step into kernel module mapping region. > > BTW, I am working on separate randomization of kernel physical and virtual > address , will post it. But it won't conflict with this because I don't > think it can be accepted in a short time. Before that this patch truly > fix the kexec/kdump bug when kaslr is compiled in. > > Thanks > Baoquan > > > > > Reported-by: Baoquan He > > Signed-off-by: Kees Cook > > Cc: stable@vger.kernel.org > > --- > > This is a reimplementation of Baoquan's "kaslr: check if kernel location is > > changed", which performs the check without needing to change the function > > declaration. This should have exactly the same effect, but I dropped Vivek's > > Ack and Thomas's Test, since it's technically a different patch. > > --- > > arch/x86/boot/compressed/misc.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c > > index dcc1c536cc21..a950864a64da 100644 > > --- a/arch/x86/boot/compressed/misc.c > > +++ b/arch/x86/boot/compressed/misc.c > > @@ -373,6 +373,8 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap, > > unsigned long output_len, > > unsigned long run_size) > > { > > + unsigned char *output_orig = output; > > + > > real_mode = rmode; > > > > sanitize_boot_params(real_mode); > > @@ -421,7 +423,12 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap, > > debug_putstr("\nDecompressing Linux... "); > > decompress(input_data, input_len, NULL, NULL, output, NULL, error); > > parse_elf(output); > > - handle_relocations(output, output_len); > > + /* > > + * 32-bit always performs relocations. 64-bit relocations are only > > + * needed if kASLR has chosen a different load address. > > + */ > > + if (!IS_ENABLED(CONFIG_X86_64) || output != output_orig) > > + handle_relocations(output, output_len); > > debug_putstr("done.\nBooting the kernel.\n"); > > return output; > > } > > -- > > 1.9.1 > > > > > > -- > > Kees Cook > > Chrome OS Security > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/