Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932136AbcDOT0O (ORCPT ); Fri, 15 Apr 2016 15:26:14 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:36181 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932120AbcDOT0K (ORCPT ); Fri, 15 Apr 2016 15:26:10 -0400 MIME-Version: 1.0 In-Reply-To: <20160415083105.GG30715@gmail.com> References: <1460672954-32567-1-git-send-email-keescook@chromium.org> <1460672954-32567-8-git-send-email-keescook@chromium.org> <20160415083105.GG30715@gmail.com> Date: Fri, 15 Apr 2016 12:26:08 -0700 X-Google-Sender-Auth: AdCtXB0AC1OgA9vhzD6m-fxZBr0 Message-ID: Subject: Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation From: Kees Cook To: Ingo Molnar Cc: Yinghai Lu , Junjie Mao , Josh Triplett , Andrew Morton , Baoquan He , Ard Biesheuvel , Matt Redfearn , "x86@kernel.org" , "H. Peter Anvin" , Ingo Molnar , Borislav Petkov , Vivek Goyal , Andy Lutomirski , lasse.collin@tukaani.org, Dave Young , "kernel-hardening@lists.openwall.com" , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1827 Lines: 53 On Fri, Apr 15, 2016 at 1:31 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> From: Yinghai Lu >> >> 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? I'm not sure why it's that specific value, but the old method used the section's ELF _file_ position, not the virtual address, and that seemed to cause the problem. > >> [...] 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? You got it. Thanks again for digging through all this! -Kees -- Kees Cook Chrome OS & Brillo Security