Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

[H. Peter Anvin]

On 04/15/2013 02:59 PM, Kees Cook wrote:
>>
>> The *physical* mapping, where it lands in RAM, is completely
>> independent, and if you're going to randomize the latter, there is no
>> reason it has to match the former.  Instead, randomize it freely.
> 
> Ah, gotcha. I don't see much benefit in doing this as it would make
> the 32-bit and 64-bit logic pretty different without much real-world
> gain, IMO.
> 

You *have* to make them different anyway.  Otherwise you aren't really
doing anything useful on x86-64.

Seriously, do it right if anything.

I also am starting to think that this really would be done better being
integrated with the decompressor code, since that code already ends up
moving the code around... no reason to do this again.

>> That is different from the i386 kernel which runs at its
>> physical-mapping address.
>>
>> Incidentally, for performance reasons please avoid locating the kernel
>> below CONFIG_PHYSICAL_ADDRESS if possible.
> 
> You mean CONFIG_PHYSICAL_START? This is already done in aslr.S via
> LOAD_PHYSICAL_ADDR which is calculated from the
> CONFIG_PHYSICAL_ALIGN-masked CONFIG_PHYSICAL_START.
> 
>> Also make sure your code works with more than 128 e820 entries.
> 
> There should be no problem here; we're using edi to count them.

More than 128 entries are fed via a different protocol.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/