Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1424815 > unrolled thread

Re: [PATCH v9 5/5] x86/KASLR: Allow randomization below load address

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 5/5] x86/KASLR: Allow randomization below load address Ingo Molnar <mingo@kernel.org> - 2016-06-17 10:50 +0200
    Re: [PATCH v9 5/5] x86/KASLR: Allow randomization below load address Kees Cook <keescook@chromium.org> - 2016-06-17 17:50 +0200
      Re: [PATCH v9 5/5] x86/KASLR: Allow randomization below load address Yinghai Lu <yinghai@kernel.org> - 2016-06-17 20:50 +0200

#1424815 — Re: [PATCH v9 5/5] x86/KASLR: Allow randomization below load address

* Kees Cook <keescook@chromium.org> wrote:

> From: Yinghai Lu <yinghai@kernel.org>
> 
> Currently the physical randomization's lower boundary is the original
> kernel load address. For bootloaders that load kernels into very high
> memory (e.g. kexec), this means randomization takes place in a very small
> window at the top of memory, ignoring the large region of physical memory
> below the load address.
> 
> Since mem_avoid is already correctly tracking the regions that must be
> avoided, this patch changes the minimum address to whatever is less:
> 512M (to conservatively avoid unknown things in lower memory) or the
> load address. Now, for example, if the kernel is loaded at 8G, [512M,
> 8G) will be added into possible physical memory positions.
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> [kees: rewrote changelog, refactor to use min()]
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  arch/x86/boot/compressed/kaslr.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index d0a823df183b..304c5c369aff 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -492,7 +492,7 @@ void choose_random_location(unsigned long input,
>  			    unsigned long output_size,
>  			    unsigned long *virt_addr)
>  {
> -	unsigned long random_addr;
> +	unsigned long random_addr, min_addr;
>  
>  	/* By default, keep output position unchanged. */
>  	*virt_addr = *output;
> @@ -517,8 +517,11 @@ void choose_random_location(unsigned long input,
>  	/* Record the various known unsafe memory ranges. */
>  	mem_avoid_init(input, input_size, *output);
>  
> +	/* Low end should be the smaller of 512M or initial location. */
> +	min_addr = min(*output, 512UL << 20);
> +
>  	/* Walk e820 and find a random address. */
> -	random_addr = find_random_phys_addr(*output, output_size);
> +	random_addr = find_random_phys_addr(min_addr, output_size);
>  	if (!random_addr) {
>  		warn("KASLR disabled: could not find suitable E820 region!");
>  	} else {

There's no explanation in the code or in the changelog of why 512M was picked as 
the lower limit.

Thanks,

	Ingo

[toc] | [next] | [standalone]

#1425256

On Fri, Jun 17, 2016 at 1:47 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Kees Cook <keescook@chromium.org> wrote:
>
>> From: Yinghai Lu <yinghai@kernel.org>
>>
>> Currently the physical randomization's lower boundary is the original
>> kernel load address. For bootloaders that load kernels into very high
>> memory (e.g. kexec), this means randomization takes place in a very small
>> window at the top of memory, ignoring the large region of physical memory
>> below the load address.
>>
>> Since mem_avoid is already correctly tracking the regions that must be
>> avoided, this patch changes the minimum address to whatever is less:
>> 512M (to conservatively avoid unknown things in lower memory) or the
>> load address. Now, for example, if the kernel is loaded at 8G, [512M,
>> 8G) will be added into possible physical memory positions.
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>> [kees: rewrote changelog, refactor to use min()]
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  arch/x86/boot/compressed/kaslr.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
>> index d0a823df183b..304c5c369aff 100644
>> --- a/arch/x86/boot/compressed/kaslr.c
>> +++ b/arch/x86/boot/compressed/kaslr.c
>> @@ -492,7 +492,7 @@ void choose_random_location(unsigned long input,
>>                           unsigned long output_size,
>>                           unsigned long *virt_addr)
>>  {
>> -     unsigned long random_addr;
>> +     unsigned long random_addr, min_addr;
>>
>>       /* By default, keep output position unchanged. */
>>       *virt_addr = *output;
>> @@ -517,8 +517,11 @@ void choose_random_location(unsigned long input,
>>       /* Record the various known unsafe memory ranges. */
>>       mem_avoid_init(input, input_size, *output);
>>
>> +     /* Low end should be the smaller of 512M or initial location. */
>> +     min_addr = min(*output, 512UL << 20);
>> +
>>       /* Walk e820 and find a random address. */
>> -     random_addr = find_random_phys_addr(*output, output_size);
>> +     random_addr = find_random_phys_addr(min_addr, output_size);
>>       if (!random_addr) {
>>               warn("KASLR disabled: could not find suitable E820 region!");
>>       } else {
>
> There's no explanation in the code or in the changelog of why 512M was picked as
> the lower limit.

Yinghai, do you have a rationale for this selection? I understood it
to just be a very conservative target to avoid anything in low
physical memory, but perhaps there is a better reason?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1425383

On Fri, Jun 17, 2016 at 8:44 AM, Kees Cook <keescook@chromium.org> wrote:
>>
>> There's no explanation in the code or in the changelog of why 512M was picked as
>> the lower limit.
>
> Yinghai, do you have a rationale for this selection? I understood it
> to just be a very conservative target to avoid anything in low
> physical memory, but perhaps there is a better reason?

when kernel is not loaded high at first, then *output should be 16M or so,
so no change.

when kernel is loaded high to save the low address space, don't want to
KASL to pull back to low address again.
If choose 4G, on 4G+512M config, when kernel is loaded high, kasl may
not work to chose range from 4G.
so I choose 512M, just stay away range for KERNEL_IMAGE_SIZE.

Thanks

Yinghai

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web