public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Pingfan Liu <kernelfans@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Chao Fan <fanc.fnst@cn.fujitsu.com>,
	x86@kernel.org
Subject: Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage
Date: Mon, 10 Sep 2018 07:33:09 +0800	[thread overview]
Message-ID: <20180909233309.GU1740@192.168.1.3> (raw)
In-Reply-To: <1536201382-13133-1-git-send-email-kernelfans@gmail.com>

Hi Pingfan,

On 09/06/18 at 10:36am, Pingfan Liu wrote:
> commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge
> pages when doing physical randomization (KASLR)") and commit
> 9b912485e0e7 ("x86/boot/KASLR: Add two new functions for 1GB huge pages
> handling") prevent the physical load addr of kernel from spoiling a good
> candidate of GiB page. But the algorithm deterministicly chooses the most
> front GiB page for hugetlb, and sacrifices the randomness, which
> is the heart of the KASLR. This patch tries to enlarge the randomness in
> the cases where hugepages=X < the num Y of good candidate of GiB
> page.

Better tell how you improve in cover letter or patch log.

> To comparison, taking a typical KVM guest for example, the head 3GiB mem
> can not be used as GiB hugetlb. Denoting the total mem size as Z(GiB), when
> Z=5, then Y=2, assuming X=1, the randomness range before this patch is
> 4GiB, after this patch is 5GiB, and get a 25% improvement of randomness.
> If Z=6, then Y=3, assuming X=2, the improvement equals: 50%( 6/(6-2) - 1);
> assuming X=1, the improvement will be: 20% (6/(6-1) - 1)

Hmm, what if hugepages=1, or 2, even 100, but system owns 1PB memory?

Secondly, even in the case that hugepages=1, system memory is 5G, if no
'movable_node' specified, the last 1G can't be chosen for hugepage.
Because memblock will allocate memory top to down. This is not
improving, but make the code not work.

Lastly, getting better randomness is the heart of KASLR, while
process_mem_region() is the heart of kernel KASLR code. Unless the
current code blocks serious fix, we'd better not touch it. Keeping
it can make the current code logic simple and more readable. It's
like a proved running well machine, we just dig out the unwanted
middle, feed the good head and tail regions into it, then it gives
back good slot for kernel position one by one.

To sum up, I personally think this patchset is not a good idea.

Thanks
Baoquan

  parent reply	other threads:[~2018-09-10  3:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06  2:36 [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage Pingfan Liu
2018-09-06  2:36 ` [PATCH 1/3] x86/boot/KASLR: change the prototypes of process_efi_entries/process_e820_entries Pingfan Liu
2018-09-06  2:36 ` [PATCH 2/3] x86/boot/KASLR: change the prototype of process_mem_region() to meet the align requirement Pingfan Liu
2018-09-06  2:36 ` [PATCH 3/3] x86/boot/KASLR: enhance randomness when using GiB hugepage Pingfan Liu
2018-09-06  4:07 ` [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr " Chao Fan
2018-09-06  5:58   ` Pingfan Liu
2018-09-06 10:00     ` Chao Fan
2018-09-09 23:33 ` Baoquan He [this message]
2018-09-10  6:47   ` Pingfan Liu

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=20180909233309.GU1740@192.168.1.3 \
    --to=bhe@redhat.com \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=kernelfans@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox