From: Greg Thelen <gthelen@google.com>
To: Junjie Mao <eternal.n08@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, Josh Triplett <josh@joshtriplett.org>,
Matt Fleming <matt.fleming@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Vivek Goyal <vgoyal@redhat.com>, Andi Kleen <ak@linux.intel.com>,
Fengguang Wu <fengguang.wu@intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v3] x86, kaslr: Prevent .bss from overlaping initrd
Date: Mon, 17 Nov 2014 18:17:20 -0800 [thread overview]
Message-ID: <xr9361ed9rrj.fsf@gthelen.mtv.corp.google.com> (raw)
In-Reply-To: <1414762838-13067-1-git-send-email-eternal.n08@gmail.com>
On Fri, Oct 31 2014, Junjie Mao wrote:
> When choosing a random address, the current implementation does not take into
> account the reversed space for .bss and .brk sections. Thus the relocated kernel
> may overlap other components in memory. Here is an example of the overlap from a
> x86_64 kernel in qemu (the ranges of physical addresses are presented):
>
> Physical Address
>
> 0x0fe00000 --+--------------------+ <-- randomized base
> / | relocated kernel |
> vmlinux.bin | (from vmlinux.bin) |
> 0x1336d000 (an ELF file) +--------------------+--
> \ | | \
> 0x1376d870 --+--------------------+ |
> | relocs table | |
> 0x13c1c2a8 +--------------------+ .bss and .brk
> | | |
> 0x13ce6000 +--------------------+ |
> | | /
> 0x13f77000 | initrd |--
> | |
> 0x13fef374 +--------------------+
>
> The initrd image will then be overwritten by the memset during early
> initialization:
>
> [ 1.655204] Unpacking initramfs...
> [ 1.662831] Initramfs unpacking failed: junk in compressed archive
>
> This patch prevents the above situation by requiring a larger space when looking
> for a random kernel base, so that existing logic can effectively avoids the
> overlap.
>
> Fixes: 82fa9637a2 ("x86, kaslr: Select random position from e820 maps")
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Junjie Mao <eternal.n08@gmail.com>
> [kees: switched to perl to avoid hex translation pain in mawk vs gawk]
> [kees: calculated overlap without relocs table]
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: stable@vger.kernel.org
> ---
> This version updates the commit log only.
>
> Kees, please help review the documentation. Thanks!
>
> Best Regards
> Junjie Mao
[...]
> diff --git a/arch/x86/tools/calc_run_size.pl b/arch/x86/tools/calc_run_size.pl
> new file mode 100644
> index 000000000000..0b0b124d3ece
> --- /dev/null
> +++ b/arch/x86/tools/calc_run_size.pl
> @@ -0,0 +1,30 @@
> +#!/usr/bin/perl
> +#
> +# Calculate the amount of space needed to run the kernel, including room for
> +# the .bss and .brk sections.
> +#
> +# Usage:
> +# objdump -h a.out | perl calc_run_size.pl
> +use strict;
> +
> +my $mem_size = 0;
> +my $file_offset = 0;
> +
> +my $sections=" *[0-9]+ \.(?:bss|brk) +";
> +while (<>) {
> + if (/^$sections([0-9a-f]+) +(?:[0-9a-f]+ +){2}([0-9a-f]+)/) {
> + my $size = hex($1);
> + my $offset = hex($2);
> + $mem_size += $size;
> + if ($file_offset == 0) {
> + $file_offset = $offset;
> + } elsif ($file_offset != $offset) {
> + die ".bss and .brk lack common file offset\n";
> + }
> + }
> +}
> +
> +if ($file_offset == 0) {
> + die "Never found .bss or .brk file offset\n";
> +}
> +printf("%d\n", $mem_size + $file_offset);
Given that bss and brk are nobits (i.e. only ALLOC) sections, does
file_offset make sense as a load address. This fails with gold:
$ git checkout v3.18-rc5
$ make # with gold
[...]
..bss and .brk lack common file offset
..bss and .brk lack common file offset
..bss and .brk lack common file offset
..bss and .brk lack common file offset
MKPIGGY arch/x86/boot/compressed/piggy.S
Usage: arch/x86/boot/compressed/mkpiggy compressed_file run_size
make[2]: *** [arch/x86/boot/compressed/piggy.S] Error 1
make[1]: *** [arch/x86/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2
In ld.bfd brk/bss file_offsets match, but they differ with ld.gold:
$ objdump -h vmlinux.ld
[...]
0 .text 00818bb3 ffffffff81000000 0000000001000000 00200000 2**12
CONTENTS, ALLOC, LOAD, READONLY, CODE
[...]
26 .bss 000e0000 ffffffff81fe8000 0000000001fe8000 013e8000 2**12
ALLOC
27 .brk 00026000 ffffffff820c8000 00000000020c8000 013e8000 2**0
ALLOC
$ objdump -h vmlinux.ld | perl arch/x86/tools/calc_run_size.pl
21946368
# aka 0x14ee000
$ objdump -h vmlinux.gold
[...]
0 .text 00818bb3 ffffffff81000000 0000000001000000 00001000 2**12
CONTENTS, ALLOC, LOAD, READONLY, CODE
[...]
26 .bss 000e0000 ffffffff81feb000 0000000001feb000 00e90000 2**12
ALLOC
27 .brk 00026000 ffffffff820cb000 00000000020cb000 00f70000 2**0
ALLOC
next prev parent reply other threads:[~2014-11-18 2:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 13:40 Junjie Mao
2014-10-31 16:11 ` Kees Cook
2014-11-01 21:24 ` [tip:x86/urgent] " tip-bot for Junjie Mao
2014-11-18 2:17 ` Greg Thelen [this message]
2014-11-18 2:23 ` [PATCH v3] " Greg Thelen
2014-11-19 16:26 ` H. Peter Anvin
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=xr9361ed9rrj.fsf@gthelen.mtv.corp.google.com \
--to=gthelen@google.com \
--cc=ak@linux.intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=eternal.n08@gmail.com \
--cc=fengguang.wu@intel.com \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome