Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

[Baoquan He]

On 03/03/17 at 03:28pm, Borislav Petkov wrote:
> On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote:
> > And another meaning of defining kernel iamge size and mapping size
> > differently is we can randomize the limited kernel image in the mapping
> > area. If they are the same or kernel image can be very large, the
> > position will be fixed or very few, kernel text KASLR will be
> > meaningless.
> 
> This is simply not true:
> 
> @@ -408,9 +408,9 @@ static unsigned long find_random_virt_addr(unsigned long minimum,
>         /*
>          * There are how many CONFIG_PHYSICAL_ALIGN-sized slots
>          * that can hold image_size within the range of minimum to
> -        * KERNEL_IMAGE_SIZE?
> +        * KERNEL_MAPPING_SIZE?
>          */
> -       slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
> +       slots = (KERNEL_MAPPING_SIZE - minimum - image_size) /
>                  CONFIG_PHYSICAL_ALIGN + 1;
> 
> *With* kaslr, KERNEL_IMAGE_SIZE = 1G and KERNEL_MAPPING_SIZE = 1G.
> Before your patch KERNEL_IMAGE_SIZE = 1G too with kaslr enabled.

512M and 1G is the first case, just an example. Usually kernel image size
is only about 20M, from my laptop.

Yes, before KERNEL_IMAGE_SIZE is 1G with kaslr enabled. when you
suggested taking a fixed size for the KERNEL_IMAGE_SIZE, but not changed
back and forth with the kaslr set or not, I started to consider this.

See the 1G, hard-constrainted because of level2_kernel_pgt. In the
future we could put kernel mapping area in another place to remove the
1G limitation, could be 10G or 512G since virtual address are so
redundent, just an assumption, kernel KASLR can benefit from this
actually, but we can't make upper value of kernel image size also be
that big. That will make linker script checking lose meaning.

Thanks
Baoquan