From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758611AbcEFT3z (ORCPT ); Fri, 6 May 2016 15:29:55 -0400 Received: from mail.skyhub.de ([78.46.96.112]:51182 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758152AbcEFT3x (ORCPT ); Fri, 6 May 2016 15:29:53 -0400 Date: Fri, 6 May 2016 21:29:46 +0200 From: Borislav Petkov To: Kees Cook Cc: LKML , Andrew Morton , Andy Lutomirski , Dave Young , "H. Peter Anvin" , Andy Lutomirski , Linus Torvalds , Denys Vlasenko , Thomas Gleixner , Brian Gerst , Yinghai Lu , Peter Zijlstra , Vivek Goyal , Baoquan He , Ingo Molnar , "linux-tip-commits@vger.kernel.org" Subject: Re: [tip:x86/boot] x86/KASLR: Consolidate mem_avoid[] entries Message-ID: <20160506192946.GS24044@pd.tnic> References: <1462486436-3707-3-git-send-email-keescook@chromium.org> <20160506160839.GN24044@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.