linux-kernel - Re: [tip:x86/boot] x86/KASLR: Consolidate mem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160506192946.GS24044@pd.tnic>
Date:	Fri, 6 May 2016 21:29:46 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Kees Cook <keescook@...omium.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Dave Young <dyoung@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Brian Gerst <brgerst@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Vivek Goyal <vgoyal@...hat.com>, Baoquan He <bhe@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/boot] x86/KASLR: Consolidate mem_avoid[] entries

On Fri, May 06, 2016 at 11:16:50AM -0700, Kees Cook wrote:
> I can expand them in the change logs, but it helps to keep reinforcing
> their names since all the variables are named using these.

Sure, in the comments in the code, but the commit messages should be more
dealing with the big picture and explaining to normal humans too :)

> This was an earlier attempt by Baoquan to fully explain the reasoning
> in this code since I couldn't understand it. He added the specific
> conditions, observations, and added the diagram. The goal is to prove
> that the changes to mem_avoid are safe since mistakes here lead to
> really hard to debug bugs.

So add that last sentence :)

> Well, no, these are ranges, so literally what it says.
> "output+init_size-ZO_INIT_SIZE" is the start of the compressed image
> (ZO). It's position is now found from the end of the buffer, which is
> output+init_size (VO's position plus VO's total run size) minus the
> total run size of ZO.

I meant the range is of ZO_INIT_SIZE size. But I like this here
explanation better, maybe add it...

> Heh. Yeah, and this is LESS confusing than when the ZO wasn't aligned
> to the end of the buffer. A whole other set of conditions vanish now.
> I will try to further explain these.

Thanks, the whole picture is certainly becoming clearer slowly, so keep
doin' whatcha doin'! :-)

> Ah! Yes, excellent. I'll actually use an enum so I can get
> MEM_AVOID_MAX automatically.

Yap.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.