From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753730AbcDOIbQ (ORCPT ); Fri, 15 Apr 2016 04:31:16 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36020 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753689AbcDOIbL (ORCPT ); Fri, 15 Apr 2016 04:31:11 -0400 Date: Fri, 15 Apr 2016 10:31:05 +0200 From: Ingo Molnar To: Kees Cook 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 Subject: Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation Message-ID: <20160415083105.GG30715@gmail.com> References: <1460672954-32567-1-git-send-email-keescook@chromium.org> <1460672954-32567-8-git-send-email-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1460672954-32567-8-git-send-email-keescook@chromium.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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? > [...] 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Sender: Ingo Molnar Date: Fri, 15 Apr 2016 10:31:05 +0200 From: Ingo Molnar Message-ID: <20160415083105.GG30715@gmail.com> References: <1460672954-32567-1-git-send-email-keescook@chromium.org> <1460672954-32567-8-git-send-email-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1460672954-32567-8-git-send-email-keescook@chromium.org> Subject: [kernel-hardening] Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation To: Kees Cook 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 List-ID: * 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? > [...] 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