linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Matt Fleming <matt.fleming@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@suse.de>, Baoquan He <bhe@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jiri Kosina <jkosina@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>
Subject: Re: [PATCH v3 2/7] x86, boot: Move ZO to end of buffer
Date: Mon, 9 Mar 2015 18:04:08 -0700	[thread overview]
Message-ID: <CAE9FiQUcmKJQm5FTADa10y6Ur1v-NfQ7gTT0HZfAWVpnRY3AkQ@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jJFms+vYOtEpVAQ6iZXM45uYF70a=vgyb72T0uRkf8c0g@mail.gmail.com>

On Mon, Mar 9, 2015 at 5:54 PM, Kees Cook <keescook@chromium.org> wrote:
> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> Boris found data from boot stage can not be used kernel stage.
>
> "... be used during kernel stage."
>
> Also, can you give a specific example of this problem? (Which data, used how?)
>
>> Bootloader allocate buffer according to init_size in hdr, and load the
>> ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
>> During running of ZO, ZO move itself to the middle of buffer at
>> z_extract_offset to make sure that decompressor would not have output
>> overwrite input data before input data get consumed.
>> After decompressor is called, VO (vmlinux) use whole buffer from start,
>> and ZO code and data section is overlapped with VO bss section.
>> And later VO/clear_bss() clear them before code in arch/x86/kernel/setup.c
>> access them.
>>
>> To make the data survive that later, we should avoid the overlapping.
>> At first move ZO close the end of buffer instead of middle of the buffer,
>> that will move out ZO data out of VO bss area.
>>
>> Also after that we can find out where is data section of copied ZO
>> instead of guessing. That will aslr mem_avoid array filling for
>
> "That will make aslr mem_avoid array ..."
>
>> new buffer seaching much simple.
>>
>> And rename z_extract_offset to z_min_extract_offset, as it is
>> actually the minimum offset for extracting now.
>>
>> To keep the final real extract_offset to be page aligned like
>> min_extract_offset, we need make VO _end and ZO _end both
>> page aligned to make sure init_size always page aligned.
>>
>> Next patch will add ZO data size to init_size, so it will make sure
>> ZO data is even out of VO brk area.
>
> This seems like a reasonable idea, but I think the changes should be
> noted/updated in misc.c since a lot of effort was made to make the
> in-memory foot print as small as possible.

Yes, that explanation in misc.c is very good about extra bytes, and it should
still stand. Also need to make mkpiggy.c to point to it.
We need to add more info about in head_32/64.c actually we need move
to end of the buffer.

> These changes do expand the
> size of the loaded kernel, IIUC. If not in this patch, maybe in 5/7?

It extend about 256k for init_size.  should be 3/7.
but that is only for decompress time. Final VO (vmlinux) run size
is not changed.

Thanks

Yinghai

  reply	other threads:[~2015-03-10  1:04 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-07 22:07 [PATCH v3 0/7] x86, boot: clean up kasl Yinghai Lu
2015-03-07 22:07 ` [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size Yinghai Lu
2015-03-09 12:49   ` Borislav Petkov
2015-03-09 15:58     ` Ingo Molnar
2015-03-09 15:58       ` Borislav Petkov
2015-03-09 19:35     ` Yinghai Lu
2015-03-09 20:00       ` Borislav Petkov
2015-03-09 20:06         ` Yinghai Lu
2015-03-09 20:18           ` Borislav Petkov
2015-03-09 21:28             ` Yinghai Lu
2015-03-10  0:42   ` Kees Cook
2015-03-13 12:27   ` Ingo Molnar
2015-03-14  2:47     ` Yinghai Lu
2015-03-14  7:53       ` Ingo Molnar
2015-03-14  9:59         ` Borislav Petkov
2015-03-16 10:06           ` [PATCH] Revert "x86/mm/ASLR: Propagate base load address calculation" Borislav Petkov
2015-03-16 12:11             ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2015-03-16 19:32               ` Yinghai Lu
2015-03-16 13:56             ` [PATCH] " Jiri Kosina
2015-03-16 19:15               ` Yinghai Lu
2015-03-17  8:14                 ` Ingo Molnar
2015-03-07 22:07 ` [PATCH v3 2/7] x86, boot: Move ZO to end of buffer Yinghai Lu
2015-03-10  0:54   ` Kees Cook
2015-03-10  1:04     ` Yinghai Lu [this message]
2015-03-10  5:59     ` Borislav Petkov
2015-03-10  8:00   ` Borislav Petkov
2015-03-10  9:34     ` Jiri Kosina
2015-03-10  9:35       ` Borislav Petkov
2015-03-10 15:11     ` Yinghai Lu
2015-03-10 15:13       ` Borislav Petkov
2015-03-10 16:59     ` Kees Cook
2015-03-07 22:07 ` [PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data Yinghai Lu
2015-03-10  9:34   ` Borislav Petkov
2015-03-10 15:05     ` Yinghai Lu
2015-03-10 15:10       ` Borislav Petkov
2015-03-10 15:17         ` Yinghai Lu
2015-03-10 15:21           ` Borislav Petkov
2015-03-10 15:42             ` Yinghai Lu
2015-03-10 15:48               ` Borislav Petkov
2015-03-10 19:29                 ` Yinghai Lu
2015-03-07 22:07 ` [PATCH v3 4/7] x86, kaslr: Access the correct kaslr_enabled variable Yinghai Lu
2015-03-10  0:55   ` Kees Cook
2015-03-07 22:07 ` [PATCH v3 5/7] x86, kaslr: Consolidate mem_avoid array filling Yinghai Lu
2015-03-10  1:00   ` Kees Cook
2015-03-10  1:10     ` Yinghai Lu
2015-03-10  1:26       ` Kees Cook
2015-03-07 22:07 ` [PATCH v3 6/7] x86, boot: Split kernel_ident_mapping_init to another file Yinghai Lu
2015-03-10  1:03   ` Kees Cook
2015-03-07 22:07 ` [PATCH v3 7/7] x86, kaslr, 64bit: Set new or extra ident_mapping Yinghai Lu
2015-03-10  1:09   ` Kees Cook
2015-03-10  1:14     ` Yinghai Lu
2015-03-10  6:54       ` Yinghai Lu
2015-03-10  0:39 ` [PATCH v3 0/7] x86, boot: clean up kasl Kees Cook
2015-03-10  0:54   ` Yinghai Lu

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=CAE9FiQUcmKJQm5FTADa10y6Ur1v-NfQ7gTT0HZfAWVpnRY3AkQ@mail.gmail.com \
    --to=yinghai@kernel.org \
    --cc=bhe@redhat.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).