* Kees Cook <keesc...@chromium.org> wrote:
> From: Yinghai Lu <ying...@kernel.org>
>
> Currently, the kernel run_size (size of code plus brk and bss) is
> calculated via the shell script arch/x86/tools/calc_run_size.sh.
> It gets the file offset and mem size of for the .bss and .brk sections in
> vmlinux, and adds them as follows:
'of for'?
> So, from this we can see that the existing run_size calculation is
> 0x400000 too high.
Btw., why is it too high? Were some sections discarded?
> [...] And, as it turns out, the correct run_size is
> actually equal to VO_end - VO_text, which is certainly easier to calculate.
> _end: 0xffffffff8205f000
> _text:0xffffffff81000000
>
> 0xffffffff8205f000 - 0xffffffff81000000 = 0x105f000
>
> As a result, run_size is a simple constant, so we don't need to pass it
> around; we already have voffset.h such things.
(Typo.)
> [...] We can share voffset.h
> between misc.c and header.S instead of getting run_size in other ways.
> This patch moves voffset.h creation code to boot/compressed/Makefile,
> and switches misc.c to use the VO_end - VO_text calculation.
Btw., 'run_size' is a pretty meaningless name, it doesn't really tell us the
most
important thing: that this is the complete size of the uncompressed kernel, the
total physically continuous size we need to allocate to it so it can execute?
So can we rename it to something more expressive, such as kernel_total_size or
so?
Thanks,
Ingo
