LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com> To: Baoquan He <bhe@redhat.com> Cc: Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org, keescook@chromium.org, tglx@linutronix.de, x86@kernel.org, hpa@zytor.com, fanc.fnst@cn.fujitsu.com, yasu.isimatu@gmail.com, indou.takao@jp.fujitsu.com, douly.fnst@cn.fujitsu.com Subject: Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization Date: Tue, 29 May 2018 09:27:37 -0400 [thread overview] Message-ID: <20180529092737.10a8138b@doriath> (raw) In-Reply-To: <20180528095418.GD31261@MiWiFi-R3L-srv> On Mon, 28 May 2018 17:54:18 +0800 Baoquan He <bhe@redhat.com> wrote: > On 05/23/18 at 03:10pm, Luiz Capitulino wrote: > > On Fri, 18 May 2018 19:28:36 +0800 > > Baoquan He <bhe@redhat.com> 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. > > Exactly. > > 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 > yes. Makes sense. Since the KASLR code already scans memory regions looking for regions to skip and since this series just uses that, I think this is a good solution to the problem: Reviewed-and-Tested-by: Luiz Capitulino <lcapitulino@redhat.com> > > > > > 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, > > Ping! > > 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 > right? > > Thanks > Baoquan >
prev parent reply other threads:[~2018-05-29 13:27 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 2018-05-29 13:27 ` Luiz Capitulino [this message]
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=20180529092737.10a8138b@doriath \ --to=lcapitulino@redhat.com \ --cc=bhe@redhat.com \ --cc=douly.fnst@cn.fujitsu.com \ --cc=fanc.fnst@cn.fujitsu.com \ --cc=hpa@zytor.com \ --cc=indou.takao@jp.fujitsu.com \ --cc=keescook@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ --cc=yasu.isimatu@gmail.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: linkBe 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).