linux-kernel - Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

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:   Wed, 12 Sep 2018 12:01:35 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Baoquan He <bhe@...hat.com>
Cc:     tglx@...utronix.de, hpa@...or.com, thgarnie@...gle.com,
        kirill.shutemov@...ux.intel.com, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of
 vmemmap region


* Baoquan He <bhe@...hat.com> wrote:

> > BTW., isn't that 'vaddr_end for KASLR' entry position inaccurate? In the typical case it could 
> > very well be that by chance all 3 areas end up being randomized into the first 64 TB region, 
> > right?
> 
> Hmm, I think it means the whole space where KASLR can be allowed to
> randomize. [vaddr_start, vaddr_end] is a scope, KASLR algorithm can
> only move memory regions inside this area. It doesn't mean the final
> result of KASLR, or any typical case of them.
> 
> vaddr_start = pgtable_l5_enabled() ? __PAGE_OFFSET_BASE_L5 : __PAGE_OFFSET_BASE_L4;
> vaddr_end = CPU_ENTRY_AREA_BASE;

Ok.

> > > With this superfluous address space as well as changing the starting address
> > > of each memory region to be PUD level, namely 1 GB aligned, we can have
> > > thousands of candidate position to locate those three memory regions.
> > 
> > Would be nice provide the number of bits randomized, maximum, from which the number of GBs of 
> > physical RAM has to be subtracted.
> > 
> > Because 'thousands' of randomization targets is *excessively* poor randomization - caused by 
> > the ridiculously high rounding to 1GB. It would be _very_ nice to extend randomization to at 
> > least 2MB boundaries instead. (If the half cacheline of PTE entries possibly 'wasted' is an 
> > issue we could increase that to 128 MB, but should start with 2MB first.)
> > 
> > That would instantly multiply the randomization selection by 512 ...
> 
> This may involve critical code changes. E.g in below commit, when we
> copy page table, we just need go deep into PUD level since PAGE_OFFSET
> is PUD_SIZE aligned, now if 2M aligned, we need deep into PMD level. I
> can only think of this about this issue. Surely, I can do more
> investigation and see what need be done to achieve the goal.

Yeah, would be nice to do, it would also test the robustness of all this code.
Obviously done after the cleanups, fixes and simpler changes.

It would be a _really_ nice feature adding about 9 bits of absolute randomization and 3x9 bits 
of relative randomization between the ranges.

> Sure, will do according to your suggestion.

Thanks!!

	Ingo