kernel-hardening - Re: [PATCH v5 07/21] x86, boot: Fix run

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160415083105.GG30715@gmail.com>
Date: Fri, 15 Apr 2016 10:31:05 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Yinghai Lu <yinghai@...nel.org>, Junjie Mao <eternal.n08@...il.com>,
	Josh Triplett <josh@...htriplett.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Baoquan He <bhe@...hat.com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Matt Redfearn <matt.redfearn@...tec.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>, Vivek Goyal <vgoyal@...hat.com>,
	Andy Lutomirski <luto@...nel.org>, lasse.collin@...aani.org,
	Dave Young <dyoung@...hat.com>, kernel-hardening@...ts.openwall.com,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation


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

> From: Yinghai Lu <yinghai@...nel.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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.