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 <b...@redhat.com> > Signed-off-by: Kees Cook <keesc...@chromium.org> > Cc: sta...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/