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]

Message-ID: <20180906040723.GC8555@localhost.localdomain>
Date:   Thu, 6 Sep 2018 12:07:23 +0800
From:   Chao Fan <fanc.fnst@...fujitsu.com>
To:     Pingfan Liu <kernelfans@...il.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 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.

>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.

If there is something wrong in my understanding, please let me know.

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
>
>
>