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

[Kees Cook]

On Wed, Mar 9, 2016 at 5:40 AM, Baoquan He <bhe@xxxxxxxxxx> wrote:
> On 03/08/16 at 10:24am, Kees Cook wrote:
>> On Mon, Mar 7, 2016 at 9:34 PM, Baoquan He <bhe@xxxxxxxxxx> 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