All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Thomas Garnier <thgarnie@google.com>
Cc: linux-nvdimm@lists.01.org, Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: KASLR causes intermittent boot failures on some systems
Date: Wed, 19 Apr 2017 22:55:17 +0800	[thread overview]
Message-ID: <20170419145517.GB2311@x1> (raw)
In-Reply-To: <CAJcbSZEbrOfnMQhr2dA0HBqogo0dYsEGCGsEbPMh1kM9tX4tEA@mail.gmail.com>

On 04/19/17 at 07:27am, Thomas Garnier wrote:
> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He <bhe@redhat.com> wrote:
> > Hi all,
> >
> > I login in Jeff's system, and added debug code, no clue found. However
> > DaveY found he disabled page_offset randomization only and the efi issue
> > won't be seen on his system with kaslr enabled. I did it too on Jeff's
> > pmem system, it has the same result. I have rebooted several times, all
> > boot successfully. In the current code, no __PAGE_OFFSET_BASE is used
> > directly, don't know why it failed.
> 
> Great! I still cannot repro it.
> 
> >
> > Does anyone have any idea or hint I can try? I read pmem code about
> > the devm_nsio_enable/pmem_attach_disk/arch_add_memory, have no idea yet.
> 
> I would test couple things:
>  - Set page_offset_base to 0 by default and set it to
> __PAGE_OFFSET_BASE in kernel_randomize_memory (without randomizing
> it). If it crashes on a low address, it might be due to using __va or
> PAGE_OFFSET in general before randomization is done.

Thanks, Thomas!

Changed code like below, it should have the same effect as you suggested.

@@ -140,6 +140,8 @@ void __init kernel_randomize_memory(void)
                 * Select a random virtual address using the extra entropy
                 * available.
                 */
+               if (i == 0)
+                       continue;
                entropy = remain_entropy / (ARRAY_SIZE(kaslr_regions) - i);

Didn't see failure since above change applied.

>  - Does any change in __PAGE_OFFSET lead to a crash? Or only when
> __PAGE_OFFSET is on a specific range. Given that you may have to
> reboot multiple times to get a crash, I assume that a specific range
> is the problem but might be worth checking.

Good point, will check.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Thomas Garnier <thgarnie@google.com>
Cc: Jeff Moyer <jmoyer@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	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: Wed, 19 Apr 2017 22:55:17 +0800	[thread overview]
Message-ID: <20170419145517.GB2311@x1> (raw)
In-Reply-To: <CAJcbSZEbrOfnMQhr2dA0HBqogo0dYsEGCGsEbPMh1kM9tX4tEA@mail.gmail.com>

On 04/19/17 at 07:27am, Thomas Garnier wrote:
> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He <bhe@redhat.com> wrote:
> > Hi all,
> >
> > I login in Jeff's system, and added debug code, no clue found. However
> > DaveY found he disabled page_offset randomization only and the efi issue
> > won't be seen on his system with kaslr enabled. I did it too on Jeff's
> > pmem system, it has the same result. I have rebooted several times, all
> > boot successfully. In the current code, no __PAGE_OFFSET_BASE is used
> > directly, don't know why it failed.
> 
> Great! I still cannot repro it.
> 
> >
> > Does anyone have any idea or hint I can try? I read pmem code about
> > the devm_nsio_enable/pmem_attach_disk/arch_add_memory, have no idea yet.
> 
> I would test couple things:
>  - Set page_offset_base to 0 by default and set it to
> __PAGE_OFFSET_BASE in kernel_randomize_memory (without randomizing
> it). If it crashes on a low address, it might be due to using __va or
> PAGE_OFFSET in general before randomization is done.

Thanks, Thomas!

Changed code like below, it should have the same effect as you suggested.

@@ -140,6 +140,8 @@ void __init kernel_randomize_memory(void)
                 * Select a random virtual address using the extra entropy
                 * available.
                 */
+               if (i == 0)
+                       continue;
                entropy = remain_entropy / (ARRAY_SIZE(kaslr_regions) - i);

Didn't see failure since above change applied.

>  - Does any change in __PAGE_OFFSET lead to a crash? Or only when
> __PAGE_OFFSET is on a specific range. Given that you may have to
> reboot multiple times to get a crash, I assume that a specific range
> is the problem but might be worth checking.

Good point, will check.

  parent reply	other threads:[~2017-04-19 14:55 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 14:41 KASLR causes intermittent boot failures on some systems Jeff Moyer
2017-04-07 14:41 ` Jeff Moyer
2017-04-07 14:49 ` Thomas Garnier
2017-04-07 14:49   ` Thomas Garnier
2017-04-07 14:51   ` Jeff Moyer
2017-04-07 14:51     ` Jeff Moyer
2017-04-07 21:25 ` Kees Cook
2017-04-07 21:25   ` Kees Cook
2017-04-10 15:49   ` Jeff Moyer
2017-04-10 15:49     ` Jeff Moyer
2017-04-10 18:13     ` Kees Cook
2017-04-10 18:13       ` Kees Cook
2017-04-10 18:22       ` Jeff Moyer
2017-04-10 18:22         ` Jeff Moyer
2017-04-10 19:03         ` Kees Cook
2017-04-10 19:03           ` Kees Cook
2017-04-10 19:18           ` Jeff Moyer
2017-04-10 19:18             ` Jeff Moyer
2017-04-08  2:51 ` Baoquan He
2017-04-08  2:51   ` Baoquan He
2017-04-08  4:08 ` Baoquan He
2017-04-08  4:08   ` Baoquan He
2017-04-08  7:02   ` Dan Williams
2017-04-08  7:02     ` Dan Williams
2017-04-08  7:52     ` Baoquan He
2017-04-08  7:52       ` Baoquan He
2017-04-10 15:57   ` Jeff Moyer
2017-04-10 15:57     ` Jeff Moyer
2017-04-12  8:24 ` Dave Young
2017-04-12  8:24   ` Dave Young
2017-04-12  8:24   ` Dave Young
2017-04-12  8:27   ` Dave Young
2017-04-12  8:27     ` Dave Young
2017-04-12  8:27     ` Dave Young
2017-04-12  8:40   ` Dave Young
2017-04-12  8:40     ` Dave Young
2017-04-12  8:40     ` Dave Young
2017-04-12 12:52     ` Jeff Moyer
2017-04-12 12:52       ` Jeff Moyer
2017-04-12 12:52       ` Jeff Moyer
2017-04-19 13:36 ` Baoquan He
2017-04-19 13:36   ` Baoquan He
2017-04-19 14:27   ` Thomas Garnier
2017-04-19 14:27     ` Thomas Garnier
2017-04-19 14:34     ` Dan Williams
2017-04-19 14:34       ` Dan Williams
2017-04-19 14:56       ` Baoquan He
2017-04-19 14:56         ` Baoquan He
2017-04-19 14:56       ` Thomas Garnier
2017-04-19 14:56         ` Thomas Garnier
2017-04-19 14:55     ` Baoquan He [this message]
2017-04-19 14:55       ` Baoquan He
2017-04-20 13:26     ` Baoquan He
2017-04-20 13:26       ` Baoquan He
2017-04-24 20:37       ` Thomas Garnier
2017-04-24 20:37         ` Thomas Garnier
2017-04-24 20:52         ` Dan Williams
2017-04-24 20:52           ` Dan Williams
2017-04-24 23:07           ` Baoquan He
2017-04-24 23:07             ` Baoquan He
2017-04-24 23:18             ` Dan Williams
2017-04-24 23:18               ` Dan Williams
2017-04-24 23:56               ` Baoquan He
2017-04-24 23:56                 ` Baoquan He
2017-04-25  0:41             ` Thomas Garnier
2017-04-25  0:41               ` Thomas Garnier
2017-04-25  1:18               ` Baoquan He
2017-04-25  1:18                 ` Baoquan He
2017-05-01 11:32 ` Baoquan He
2017-05-01 11:32   ` Baoquan He

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=20170419145517.GB2311@x1 \
    --to=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mingo@kernel.org \
    --cc=thgarnie@google.com \
    /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.