linux-kernel - Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage

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, 6 Sep 2018 13:58:08 +0800
From:   Pingfan Liu <kernelfans@...il.com>
To:     Chao Fan <fanc.fnst@...fujitsu.com>
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Baoquan He <bhe@...hat.com>, x86@...nel.org
Subject: Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load
 addr when using GiB hugepage

On Thu, Sep 6, 2018 at 12:07 PM Chao Fan <fanc.fnst@...fujitsu.com> wrote:
>
> On Thu, Sep 06, 2018 at 10:36:19AM +0800, Pingfan Liu wrote:
>
> Hi Pingfan,
>
> >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
>
> Yes, in some situations, if Y > X, the patch would reduce the
> randomness. And to reserve a fixed 1G for huge page is not perfect
> enouth.
> But the the size of slot is so small, the size of memory is so big.
>
Yes, but this is the sense of a human,. and normally, we are protected
against the attack from a program.

> >page.
> >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.
>
> Such as your example,
> in 4G, the probability every slot chosen is about 0.00049
> in 5G, the probability every slot chosen is about 0.00039
> Yes, you did improve 25% for randomness. But I wonder if it's worth to
> improve from 0.00049 to 0.00039.
>
This is the case of least improvement.

> If there is something wrong in my understanding, please let me know.
>
Yes, you get my idea. There are two factor worth to consider. The 1st
one is the head 3GiB, if it can be reduce to 1GiB or 2GiB, then the
randomness will have a great improvement. The 2nd one is the X, which
also play a important role of the randomness.

Thanks and regards,
Pingfan

> Thanks,
> Chao Fan
>
> >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)
> >
> >Cc: Thomas Gleixner <tglx@...utronix.de>
> >Cc: Ingo Molnar <mingo@...hat.com>
> >Cc: "H. Peter Anvin" <hpa@...or.com>
> >Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
> >Cc: Baoquan He <bhe@...hat.com>
> >Cc: Chao Fan <fanc.fnst@...fujitsu.com> (authored:1/16=6%)
> >Cc: x86@...nel.org
> >
> >Pingfan Liu (3):
> >  x86/boot/KASLR: change the prototypes of
> >    process_efi_entries/process_e820_entries
> >  x86/boot/KASLR: change the prototype of process_mem_region() to meet
> >    the align requirement
> >  x86/boot/KASLR: enhance randomness when using GiB hugepage
> >
> > arch/x86/boot/compressed/kaslr.c | 228 ++++++++++++++++++++++++++-------------
> > 1 file changed, 152 insertions(+), 76 deletions(-)
> >
> >--
> >2.7.4
> >
> >
> >
>
>