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

[Baoquan He]

On 03/03/17 at 08:52pm, Baoquan He wrote:
> On 03/03/17 at 01:16pm, Borislav Petkov wrote:
> > On Fri, Mar 03, 2017 at 08:06:16PM +0800, Baoquan He wrote:
> > > OK, I am trying to make things clearer, seems I failed. I thought kernel
> > > iamge size is only allowed to be 512M at most, but can be mapped into 1G
> > > region.
> > 
> > It doesn't look like it. But we could be missing something. You could
> > try some git archeology to find out why the 512M limit. It could be "no
> > reason", it could be remnant from 32-bit, it could be anything...
> > 
> > There's the full git history here too:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/history/history.git
> > 
> > in case it helps.
> 

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. E.g 512M of kernel image, 16M aligned, there are 32 slots
we can choose to position. If kernel image can be 1g either, no
possibility to randomize at all.

> Thanks, have got all related change history below. In the last commit log
> Ingo wrote he was just trying to give more space to kernel and push
> modules up a bit, and it should be enough for a few years. My thought of
> introducing KERNEL_MAPPING_SIZE is mainly because in commit 85eb69a1
> ("x86: increase the kernel text limit to 512 MB") Ingo is trying to
> increase kernel image size, since the really large static arrays and
> building allyesconfig kernel are all bloating kernel image. I feel Ingo
> is very careful to keep the pace to increase it, guess people don't want
> to see kernel image can be made by default as 1G big at one time without
> obvious reason. AFAIK, peopel sometime have to tell how much space it
> will increae with their new feature or big change. This is a very good
> self alert with a limited but usually enough value, 512M, let people pay
> attention to the elegacy but not always many lines of code, think more
> and refector code. And linker script is the guard to check it. 
> 
> Not sure if I make myself clear. I hesitated to do that earlier, so
> finally introduce KERNEL_MAPPING_SIZE. Surely in the current case, as
> you said, 1G is hard-constrainted line, unless we decide to give a
> larger space for kernel mapping or put it other place since Intel people
> have been working on 5-level page mapping thing, we don't lack virtual
> space, but kernel mapping is too constrainted. Even though we have more
> than 1G kernel mapping space, image size still should be limited to a
> small value, like plus 128M or + 256M.
> 
> ***
> commit 85eb69a16aab5a394ce043c2131319eae35e6493
> Author: Ingo Molnar <mingo@xxxxxxx>
> Date:   Thu Feb 21 12:50:51 2008 +0100
> 
>     x86: increase the kernel text limit to 512 MB
>     
>     people sometimes do crazy stuff like building really large static
>     arrays into their kernels or building allyesconfig kernels. Give
>     more space to the kernel and push modules up a bit: kernel has
>     512 MB and modules have 1.5 GB.
>     
>     Should be enough for a few years ;-)
> 
> ***
> d4afe414    x86: rename KERNEL_TEXT_SIZE => KERNEL_IMAGE_SIZE
> Rename it to be KERNEL_IMAGE_SIZE
> 
> ***
> 88f3aec7    x86: fix spontaneous reboot with allyesconfig bzImage
> In this commit Ingo changed KERNEL_TEXT_SIZE from 40M to 128M.
> 
> > 
> > > It's fine to me, thing can be solved anyway. Will repost with
> > > KERNEL_IMAGE_SIZE by default 1G.
> > 
> > I think you should slow down first and try to find out why the 512
> > default. Then we can talk about changes.
> > 
> > -- 
> > Regards/Gruss,
> >     Boris.
> > 
> > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
> > --