lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 22 Jun 2017 11:20:32 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Chao Fan <fanc.fnst@...fujitsu.com>
Cc:     linux-kernel@...r.kernel.org, keescook@...omium.org,
        x86@...nel.org, caoj.fnst@...fujitsu.com, douly.fnst@...fujitsu.com
Subject: Re: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be
 randomized in mirror regions if existed

On 06/22/17 at 11:10am, Chao Fan wrote:
> Hi all,
> 
> After testing this issue for 100 times in total, I think this patchset
> works well.

Thanks for your effort, Chao!

Then I will repost with some modification according to the kbuild test report
and your comment, and thanks again for that. Maybe next week, there is 
urgent rhel bug now I am trying to fix.

Thanks
Baoquan

> 
> The size of physical memory in my test machine is 229G, the size of
> mirror region is 26G. In the 100 times, 50 times are with this patchset,
> 50 times are without it.
> 
> Here is my test result:
> 
> ------------------------------------------------
>             |total times|in non-mirror|in mirror
> ------------|-----------|-------------|---------
> before patch|     50    |      41     |   9
> ------------|-----------|-------------|---------
> with patch  |     50    |       0     |  50
> ------------------------------------------------
> 
> Firstly, I add the earlyprintk to get efi map when walking the efi map.
> Then get the range of mirror regions.
> In kaslr.c, add the earlyprintk to get random_addr in function
> choose_random_location, find_random_phys_addr. Then check if the address
> in which is choosen to extract kernel is in mirror region.
> 
> If there are any problems, please let me know.
> 
> Thanks,
> Chao Fan
> 
> On Thu, Jun 15, 2017 at 03:52:47PM +0800, Baoquan He wrote:
> >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.
> >
> >The functions of address range mirroring feature are as follows.
> >- The physical memory region whose descriptors in EFI memory map have
> >  EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are mirrored
> >- The function arranges such mirror region into normal zone and other region
> >  into movable zone in order to locate kernel code and data on mirror region
> >
> >So we need restrict kernel to be located inside mirror region if it
> >is existed.
> >
> >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.
> >
> >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
> >
> >
> >
> 
> 

Powered by blists - more mailing lists