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:	Mon, 15 Apr 2013 19:31:10 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Kees Cook <keescook@...omium.org>
CC:	Eric Northup <digitaleric@...gle.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@...el.com>,
	Matthew Garrett <mjg@...hat.com>,
	Matt Fleming <matt.fleming@...el.com>,
	Dan Rosenberg <drosenberg@...curity.com>,
	Julien Tinnes <jln@...gle.com>, Will Drewry <wad@...omium.org>
Subject: Re: [PATCH 6/6] x86: kaslr: relocate base offset at boot

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ