LKML Archive on
help / color / mirror / Atom feed
From: Baoquan He <>
To: Ingo Molnar <>, Luiz Capitulino <>
Subject: Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization
Date: Mon, 28 May 2018 17:54:18 +0800	[thread overview]
Message-ID: <20180528095418.GD31261@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20180523151022.102e3565@doriath>

On 05/23/18 at 03:10pm, Luiz Capitulino wrote:
> On Fri, 18 May 2018 19:28:36 +0800
> Baoquan He <> wrote:
> > > Note that it's not KASLR specific: if we had some other kernel feature that tried 
> > > to allocate a piece of memory from what appears to be perfectly usable generic RAM 
> > > we'd have the same problems!  
> > 
> > Hmm, this may not be the situation for 1GB huge pages. For 1GB huge
> > pages, the bug is that on KVM guest with 4GB ram, when user adds
> > 'default_hugepagesz=1G hugepagesz=1G hugepages=1' to kernel
> > command-line, if 'nokaslr' is specified, they can get 1GB huge page
> > allocated successfully. If remove 'nokaslr', namely KASLR is enabled,
> > the 1GB huge page allocation failed.
> Let me clarify that this issue is not specific to KVM in any way. The same
> issue happens on bare-metal, but if you have lots of memory you'll hardly
> notice it. On the other hand, it's common to create KVM guests with a few
> GBs of memory. In those guests, you may not be able to get a 1GB hugepage
> at all if kaslr is enabled.
> This series is a simple fix for this bug. It hooks up into already existing
> KASLR code that scans memory regions to be avoided. The memory hotplug
> issue is left for another day.


This issue is about kernel being randomized into good 1GB huge pages to
break later huge page allocation, and we can only scan memory to know
where 1GB huge page is located and avoid them.

The memory hotplug issue is about kernel being randomized into movable
memory regions, and we need read ACPI SRAT table to retrieve the
attribute of memory regions to know if it's movable, then avoid it if

> Now, if I understand what Ingo is saying is that he wants to see all problems
> solved with a generic solution vs. a specific solution for each problem.

Hmm, if we understand Ingo's words correctly, for these two issues,
seems there isn't a generic solution to solve both of them. We can only
fix them separately.

Hi Ingo,


Not sure if my above understanding is correct. Could you confirm if I
have understood your comments and if the solution of this patchset is


  reply	other threads:[~2018-05-28  9:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16 10:05 [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization Baoquan He
2018-05-16 10:05 ` [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling Baoquan He
2018-05-17  3:27   ` Chao Fan
2018-05-17  4:03     ` Baoquan He
2018-05-17  5:53       ` Chao Fan
2018-05-17  6:13         ` Baoquan He
2018-05-17  5:12   ` damian
2018-05-17  5:38     ` Baoquan He
2018-06-21 15:01   ` Ingo Molnar
2018-06-22 12:14     ` Baoquan He
2018-06-24  7:13       ` Ingo Molnar
2018-05-16 10:05 ` [PATCH 2/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization Baoquan He
2018-05-18  7:00 ` [PATCH 0/2] " Ingo Molnar
2018-05-18  7:43   ` Baoquan He
2018-05-18  8:19     ` Ingo Molnar
2018-05-18 11:28       ` Baoquan He
2018-05-18 12:14         ` Baoquan He
2018-05-23 19:10         ` Luiz Capitulino
2018-05-28  9:54           ` Baoquan He [this message]
2018-05-29 13:27             ` Luiz Capitulino

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180528095418.GD31261@MiWiFi-R3L-srv \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).