All of lore.kernel.org
 help / color / mirror / Atom feed
From: "'Baoquan He'" <bhe@redhat.com>
To: "Izumi, Taku" <izumi.taku@jp.fujitsu.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Fan, Chao" <fanc.fnst@cn.fujitsu.com>,
	"Cao, Jin" <caoj.fnst@cn.fujitsu.com>,
	"Dou, Liyang" <douly.fnst@cn.fujitsu.com>
Subject: Re: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed
Date: Thu, 15 Jun 2017 17:20:32 +0800	[thread overview]
Message-ID: <20170615092032.GC16181@x1> (raw)
In-Reply-To: <E86EADE93E2D054CBCD4E708C38D364A7420FFC2@G01JPEXMBYT21>

On 06/15/17 at 08:34am, Izumi, Taku wrote:
> Dear Baoquan,
> 
> > > Our customer reported that Kernel text may be located on non-mirror
> > > region (movable zone) when both address range mirroring feature and
> > > KASLR are enabled.
> 
>    I know your customer :)

LOL, have to agree.

> > > The method is very simple. If efi is enabled, just iterate all efi
> > > memory map and pick up mirror region to process for adding candidate
> > > of slot. If efi disabled or no mirror region existed, still process
> > > e820 memory map. This won't bring much efficiency loss, at worst we
> > > just go through all efi memory maps and found no mirror.
> > >
> > > One question:
> > > From code, though mirror regions are existed, they are meaningful only
> > > if kernelcore=mirror kernel option is specified. Not sure if my
> > > understanding is correct.
> 
>    Your understanding is almost correct. 
>    Only when "kernelcore=mirror" specified, the above procedure works.
>    But, if mirrored regions are existed, bootmem allocator tries to 
>    allocate from mirrored region independently of "kerenelcore=mirror" option.
> 
>    So, IMHO, kernel text is important, so putting it to mirrored (more reliable)
>    region is reasonable whether or not "kernelcore=mirror" is specified.

Ah, yeah, thanks for telling. So at boot time memblock will put mirror
region in highest priority to allocate. Then let me remove the
kernelcore=mirror handling code, the process_efi_entry will be simpler.

commit a3f5bafcc04aaf62990e0cf3ced1cc6d8dc6fe95
Author: Tony Luck <tony.luck@intel.com>
Date:   Wed Jun 24 16:58:12 2015 -0700

    mm/memblock: allocate boot time data structures from mirrored memory

> 
>    Anyway thanks for submitting patch.
>    We have Address Range Mirroring capable machine, so we'll test your patch.

Thanks a lot for help, Yasuaki Ishimatsu said he also will loan me a testing
machine when it's available.

Thanks
Baoquan

> > 
> > >
> > > NOTE:
> > > I haven't got a machine with efi mirror region enabled, so only test
> > > the
> > > e820 map processing case and the case of no mirror region on efi machine.
> > > So set this as a RFC patchset, will post formal one after above
> > > question is made clear and mirror issue test passed.
> > >
> > > Baoquan He (2):
> > >   x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map
> > >   x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if
> > >     existed
> > >
> > >  arch/x86/boot/compressed/kaslr.c | 129
> > > +++++++++++++++++++++++++++++++--------
> > >  1 file changed, 104 insertions(+), 25 deletions(-)
> > >
> > > --
> > > 2.5.5
> > >
> 

  reply	other threads:[~2017-06-15  9:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15  7:52 [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed Baoquan He
2017-06-15  7:52 ` [PATCH 1/2] x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map Baoquan He
2017-06-20  8:22   ` Chao Fan
2017-06-15  7:52 ` [PATCH 2/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed Baoquan He
2017-06-15 14:04   ` kbuild test robot
2017-06-15 15:03     ` Baoquan He
2017-06-15  8:03 ` [RFC][PATCH 0/2] " Baoquan He
2017-06-15  8:34   ` Izumi, Taku
2017-06-15  9:20     ` 'Baoquan He' [this message]
2017-06-22  3:10 ` Chao Fan
2017-06-22  3:20   ` Baoquan He
2017-06-22  3:36     ` Chao Fan

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=20170615092032.GC16181@x1 \
    --to=bhe@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.