On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He <b...@redhat.com> wrote: > Currently kaslr enabling can extend the kernel virtual address space > to 1G, next is for modules. So if kernel is loaded to above 1G, system > running will be exceptional, This happened when kexec/kdump load kernel. > > So add a check to see if the decompression output region is contained > in 1G. > > Signed-off-by: Baoquan He <b...@redhat.com> > --- > arch/x86/boot/compressed/misc.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c > index 7780a5b..d2a0eaa 100644 > --- a/arch/x86/boot/compressed/misc.c > +++ b/arch/x86/boot/compressed/misc.c > @@ -250,6 +250,11 @@ static void handle_relocations(void *output, unsigned > long output_len) > } > #endif > > + if (max_addr > CONFIG_RANDOMIZE_BASE_MAX_OFFSET) { > + debug_putstr("Random addr is not allowed. No relocation > needed... \n"); > + return; > + } > +
It's not clear to me what this is fixing. In aslr.c, process_e820_entry() should already make it impossible to select max_addr > CONFIG_RANDOMIZE_BASE_MAX_OFFSET. If you're trying to detect a non-kaslr boot, I think this is better handled in 1/4 where I suggest examining the "output" location before/after choose_kernel_location. -Kees > /* > * Calculate the delta between where vmlinux was linked to load > * and where it was actually loaded. > -- > 1.8.5.3 > -- 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/