From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Kees Cook <keescook@chromium.org>
Cc: Fengguang Wu <fengguang.wu@intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [x86, kaslr] BUG: kernel boot hang
Date: Tue, 14 Jan 2014 15:45:46 -0800 [thread overview]
Message-ID: <52D5CC2A.7030906@linux.intel.com> (raw)
In-Reply-To: <CAGXu5jJLarLeYef0eEfEuVS4pDJf_3my-5BV1O6RX+LP7=hUag@mail.gmail.com>
On 01/14/2014 03:31 PM, Kees Cook wrote:
> On Tue, Jan 14, 2014 at 3:23 PM, H. Peter Anvin <hpa@linux.intel.com> wrote:
>> On 01/14/2014 02:33 PM, Kees Cook wrote:
>>>
>>> Can you tell me how the initrd for quantal-core-x86_64.cgz was built
>>> in the qemu instances you're using? It seems like all the failures
>>> point to a problem with how kASLR is interacting with the initrd.
>>>
>>
>> If kASLR somehow causes the kernel to collide with the initrd that would
>> be problem...
>
> Agreed, but I can't reproduce this yet. The initrd is on the list of
> areas that get avoided, so the fundamental design isn't broken, but
> clearly something is busted.
>
> How long has tip:x86/kaslr been sitting in linux-next? If this is some
> interaction between kaslr and something else, perhaps merge order just
> happens to be pointing at kaslr?
>
> Regardless, all my tests so far against next-20140114 and an initramfs
> haven't seen corruption (using the given .config). I don't have the
> same initrd, though, so I'm hoping getting that will trigger the
> glitch.
>
Given our craptastic ELF parser I'm wondering if we at some point
overrun the kernel "safe memory zone" during decompression/parsing...
-hpa
next prev parent reply other threads:[~2014-01-14 23:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 13:31 [x86, kaslr] BUG: kernel boot hang Fengguang Wu
2014-01-14 16:02 ` H. Peter Anvin
2014-01-14 18:32 ` Kees Cook
2014-01-14 19:19 ` H. Peter Anvin
2014-01-14 18:26 ` Kees Cook
2014-01-14 18:47 ` H. Peter Anvin
2014-01-15 12:10 ` Fengguang Wu
2014-01-14 22:33 ` Kees Cook
2014-01-14 23:23 ` H. Peter Anvin
2014-01-14 23:31 ` Kees Cook
2014-01-14 23:45 ` H. Peter Anvin [this message]
2014-01-15 12:37 ` Fengguang Wu
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=52D5CC2A.7030906@linux.intel.com \
--to=hpa@linux.intel.com \
--cc=fengguang.wu@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.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 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.