linux-kernel - Re: [PATCH v3 16/19] x86, kaslr: Randomize physical and virtual address of kernel separately

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, 9 Mar 2016 10:07:25 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Baoquan He <bhe@...hat.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Vivek Goyal <vgoyal@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...nel.org>, lasse.collin@...aani.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Young <dyoung@...hat.com>
Subject: Re: [PATCH v3 16/19] x86, kaslr: Randomize physical and virtual
 address of kernel separately

On Wed, Mar 9, 2016 at 5:40 AM, Baoquan He <bhe@...hat.com> wrote:
> On 03/08/16 at 10:24am, Kees Cook wrote:
>> On Mon, Mar 7, 2016 at 9:34 PM, Baoquan He <bhe@...hat.com> wrote:
>> >> It seems like CONFIG_RANDOMIZE_BASE_MAX_OFFSET should have been
>> >> eliminated when the on-demand page table code was added. Once that was
>> >> added, there's no physical max any more. And virtual randomization
>> >> should have no max at all.
>> > For physically random, yes, CONFIG_RANDOMIZE_BASE_MAX_OFFSET is not
>> > needed anymore. But for virtually random,
>> > CONFIG_RANDOMIZE_BASE_MAX_OFFSET is still mandatory since kernel text
>> > mapping and kernel module mapping share the 2G virtual address space as
>> > follows. Though kaslr increase kernel text mapping from 512M to 1G, it's
>> > still limited, can't exceed CONFIG_RANDOMIZE_BASE_MAX_OFFSET.
>> >
>> > [0xffffffff80000000, 0xffffffffffffffff]
>> >
>> > But now as you suggested, I would like to change
>> > CONFIG_RANDOMIZE_BASE_MAX_OFFSET to another name because it's only
>> > valid for virtual randomization. A more specific name is better.
>>
>> Yes, right, the virtual has a 1G max, but I meant that it doesn't need
>> to be a CONFIG item any more. Physical can use physical memory max as
>> its max, and virtual max can now be calculated from the existing text
>> mapping size.
>
> Got it, it should be KERNEL_IMAGE_SIZE instead, right?

Yup, that should be right. And removing
CONFIG_RANDOMIZE_BASE_MAX_OFFSET will be a nice clean up, actually. It
can be its own patch separate from the rest of the changes. The config
was likely never needed (the Kconfigs already default to max values),
but I had it there out of a desire to make everything configurable
early on when it was a new feature.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security