[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Apr 2013 13:19:39 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Kees Cook <keescook@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 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>,
Eric Northup <digitaleric@...gle.com>, Dan Rosenberg <drosenberg@...curity.com>,
Julien Tinnes <jln@...gle.com>, Will Drewry <wad@...omium.org>
Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR
On Fri, Apr 5, 2013 at 1:05 PM, H. Peter Anvin <hpa@...or.com> wrote:
> That makes zero difference, since the issue at hand is the *virtual*
> addresses the kernel are running at. Currently, the 64-bit kernel
> always runs at 0xffffffff81000000 virtual. We can't run out of
> arbitrary bits of the 64-bit address space because of the memory model.
Not sure if I understand this.
when bzImage64 is loaded high, the kernel high address 0xffffffff81000000
is pointed to phys address above 4G without problem.
Also during arch/x86/boot/compressed/head_64.S, kernel does not parse
e820 yet, so it can not find right place for kernel yet.
bootloader already parse the e820, and it already know kernel run time size.
So it should be easy for them for crazy random range for kernel.
>
> Furthermore, dealing with the boot loaders means dealing with the boot
> loader maintainers, which can be insanely painful. Consider that Grub2,
> 10 years after this was implemented, still can't load more than one
> initramfs component.
syslinux and pxelinux could do that?
Thanks
Yinghai
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
