Messages in this thread | | | Date | Fri, 3 Mar 2017 23:07:51 +0800 | From | Baoquan He <> | Subject | Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE |
| |
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
| |