linux-kernel - Re: [PATCH 3/3] x86: kernel base offset ASLR

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]

Message-ID: <CAE9FiQU+k0j-CEvJm-D6Dch4wa8ooU8Zcry8sN0RYx=YEadiJw@mail.gmail.com>
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
--
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/