From: Kees Cook <keescook@chromium.org> To: Ingo Molnar <mingo@kernel.org> Cc: Yinghai Lu <yinghai@kernel.org>, Junjie Mao <eternal.n08@gmail.com>, Josh Triplett <josh@joshtriplett.org>, Andrew Morton <akpm@linux-foundation.org>, Baoquan He <bhe@redhat.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Matt Redfearn <matt.redfearn@imgtec.com>, "x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>, Andy Lutomirski <luto@kernel.org>, lasse.collin@tukaani.org, Dave Young <dyoung@redhat.com>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation Date: Fri, 15 Apr 2016 12:26:08 -0700 [thread overview] Message-ID: <CAGXu5j+3zO=csJuZkYsqCwD3hgCCUfJtUwGnKJZEBmga6hbJhA@mail.gmail.com> (raw) In-Reply-To: <20160415083105.GG30715@gmail.com> On Fri, Apr 15, 2016 at 1:31 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Kees Cook <keescook@chromium.org> wrote: > >> From: Yinghai Lu <yinghai@kernel.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? 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
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Ingo Molnar <mingo@kernel.org> Cc: Yinghai Lu <yinghai@kernel.org>, Junjie Mao <eternal.n08@gmail.com>, Josh Triplett <josh@joshtriplett.org>, Andrew Morton <akpm@linux-foundation.org>, Baoquan He <bhe@redhat.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Matt Redfearn <matt.redfearn@imgtec.com>, "x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>, Andy Lutomirski <luto@kernel.org>, lasse.collin@tukaani.org, Dave Young <dyoung@redhat.com>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, LKML <linux-kernel@vger.kernel.org> Subject: [kernel-hardening] Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation Date: Fri, 15 Apr 2016 12:26:08 -0700 [thread overview] Message-ID: <CAGXu5j+3zO=csJuZkYsqCwD3hgCCUfJtUwGnKJZEBmga6hbJhA@mail.gmail.com> (raw) In-Reply-To: <20160415083105.GG30715@gmail.com> On Fri, Apr 15, 2016 at 1:31 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Kees Cook <keescook@chromium.org> wrote: > >> From: Yinghai Lu <yinghai@kernel.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? 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
next prev parent reply other threads:[~2016-04-15 19:26 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-14 22:28 [PATCH v5 00/21] x86, boot: KASLR cleanup and 64-bit improvements Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 01/21] x86, KASLR: Remove unneeded boot_params argument Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 7:29 ` Ingo Molnar 2016-04-15 7:29 ` [kernel-hardening] " Ingo Molnar 2016-04-15 18:55 ` Kees Cook 2016-04-15 18:55 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 02/21] x86, KASLR: Handle kernel relocation above 2G Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 7:47 ` Ingo Molnar 2016-04-15 7:47 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:01 ` Kees Cook 2016-04-15 19:01 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 03/21] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 8:07 ` Ingo Molnar 2016-04-15 8:07 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:12 ` Kees Cook 2016-04-15 19:12 ` [kernel-hardening] " Kees Cook 2016-04-16 8:42 ` Ingo Molnar 2016-04-16 8:42 ` [kernel-hardening] " Ingo Molnar 2016-04-14 22:28 ` [PATCH v5 04/21] x86, boot: Move compressed kernel to end of decompression buffer Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 8:09 ` Ingo Molnar 2016-04-15 8:09 ` [kernel-hardening] " Ingo Molnar 2016-04-18 16:50 ` Kees Cook 2016-04-18 16:50 ` [kernel-hardening] " Kees Cook 2016-04-15 9:05 ` Ingo Molnar 2016-04-15 9:05 ` [kernel-hardening] " Ingo Molnar 2016-04-14 22:28 ` [PATCH v5 05/21] x86, boot: Calculate decompression size during boot not build Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 8:12 ` Ingo Molnar 2016-04-15 8:12 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:14 ` Kees Cook 2016-04-15 19:14 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 06/21] x86, KASLR: Update description for decompressor worst case size Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 16:17 ` Lasse Collin 2016-04-15 16:17 ` [kernel-hardening] " Lasse Collin 2016-04-14 22:29 ` [PATCH v5 07/21] x86, boot: Fix run_size calculation Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-15 8:31 ` Ingo Molnar 2016-04-15 8:31 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:26 ` Kees Cook [this message] 2016-04-15 19:26 ` Kees Cook 2016-04-16 9:00 ` Ingo Molnar 2016-04-16 9:00 ` [kernel-hardening] " Ingo Molnar 2016-04-14 22:29 ` [PATCH v5 08/21] x86, KASLR: Clean up unused code from old run_size Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 09/21] x86, KASLR: Correctly bounds-check relocations Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 10/21] x86, KASLR: Consolidate mem_avoid entries Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 11/21] x86, boot: Split out kernel_ident_mapping_init Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 12/21] x86, 64bit: Set ident_mapping for KASLR Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 13/21] x86, boot: Report overlap failures in memcpy Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-15 14:42 ` Lasse Collin 2016-04-15 14:42 ` [kernel-hardening] " Lasse Collin 2016-04-15 19:28 ` Kees Cook 2016-04-15 19:28 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 14/21] x86, KASLR: Add slot_area to manage random slots Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 15/21] x86, KASLR: Add slot_area support functions Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 16/21] x86, KASLR: Add virtual address choosing function Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 17/21] x86, KASLR: Clarify purpose of each get_random_long Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 18/21] x86, KASLR: Randomize virtual address separately Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 20/21] x86, KASLR: Remove unused slot tracking code Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 21/21] x86, KASLR: Allow randomization below load address Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAGXu5j+3zO=csJuZkYsqCwD3hgCCUfJtUwGnKJZEBmga6hbJhA@mail.gmail.com' \ --to=keescook@chromium.org \ --cc=akpm@linux-foundation.org \ --cc=ard.biesheuvel@linaro.org \ --cc=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=dyoung@redhat.com \ --cc=eternal.n08@gmail.com \ --cc=hpa@zytor.com \ --cc=josh@joshtriplett.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=lasse.collin@tukaani.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=matt.redfearn@imgtec.com \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=vgoyal@redhat.com \ --cc=x86@kernel.org \ --cc=yinghai@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.