Re: KASLR causes intermittent boot failures on some systems

From: Kees Cook <keescook@chromium.org>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Thomas Garnier <thgarnie@google.com>,
	Ingo Molnar <mingo@kernel.org>, Baoquan He <bhe@redhat.com>,
	Dan Williams <dan.j.williams@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-nvdimm@ml01.01.org
Subject: Re: KASLR causes intermittent boot failures on some systems
Date: Mon, 10 Apr 2017 11:13:12 -0700	[thread overview]
Message-ID: <CAGXu5jLN=HNRj1DGwzWP5kU9iZ54oxzYoPYnnnqzWc9M-gcwfw@mail.gmail.com> (raw)
In-Reply-To: <x49d1ck5kkk.fsf@segfault.boston.devel.redhat.com>

On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
>>> Hi,
>>>
>>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>>> regions") causes some of my systems with persistent memory (whether real
>>> or emulated) to fail to boot with a couple of different crash
>>> signatures.  The first signature is a NMI watchdog lockup of all but 1
>>> cpu, which causes much difficulty in extracting useful information from
>>> the console.  The second variant is an invalid paging request, listed
>>> below.
>>
>> Just to rule out some of the stuff in the boot path, does booting with
>> "nokaslr" solve this? (i.e. I want to figure out if this is from some
>> of the rearrangements done that are exposed under that commit, or if
>> it is genuinely the randomization that is killing the systems...)
>
> Adding "nokaslr" to the boot line does indeed make the problem go away.

Are you booting with a memmap= flag?

-Kees

-- 
Kees Cook
Pixel Security