lkml.org 
[lkml]   [2014]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/4] kaslr: check if the random addr is available
From
On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He <bhe@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 <bhe@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


\
 
 \ /
  Last update: 2014-09-05 19:41    [W:0.118 / U:1.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site