linux-kernel - Re: [RFC][PATCH] Randomize kernel base address on boot

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:	Fri, 27 May 2011 11:36:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Valdis.Kletnieks@...edu, Dan Rosenberg <drosenberg@...curity.com>,
	Tony Luck <tony.luck@...il.com>, linux-kernel@...r.kernel.org,
	davej@...hat.com, kees.cook@...onical.com, davem@...emloft.net,
	eranian@...gle.com, torvalds@...ux-foundation.org,
	adobriyan@...il.com, penberg@...nel.org, hpa@...or.com,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>, pageexec@...email.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot


* Vivek Goyal <vgoyal@...hat.com> wrote:

> On Thu, May 26, 2011 at 04:16:05PM -0400, Valdis.Kletnieks@...edu wrote:
> > On Thu, 26 May 2011 16:01:21 EDT, Vivek Goyal said:
> > 
> > > Also randomization of kernel load address at run time will probably have
> > > some issues with crashkernel=X@Y address syntax. So far user knew what
> > > address first kernel is booting from and user could speicy where to 
> > > reserve memory. Now it might happen that user specified some memory
> > > to reserve and kernel decided to occupy that space resulting in failed
> > > memory reservation for crash kernel.
> > 
> > That is however fixable - the randomizer just needs to make sure it doesn't
> > overlay the crashkernel= space, and the crashkernel needs to be started with a
> > 'norandomize' parameter.
> 
> That can be done but at the same time if kernel does not find any suitable
> range to boot from, it should override crashkernel=X@Y settings and fail
> crash memory reservation.
> 
> I guess with randomize space thing a more suitable crash kernel command
> line will be crashkernel=X where kernel decides the base address for
> second kernel depending on availability.
> 
> > If your threat model includes attacks on the
> > crashkernel that randomizing will help with, you got bigger problems. ;)
> > 
> 
> :-) I think norandomize for kdump kernel should be just fine.

Dan, please always generate a very clear printk when randomization is 
off - if we implement everything correctly then it will be impossible 
for even the admin to determine whether there's kernel image 
randomization going on on a system! :-)

Btw., systems with signed modules and with an inability for even root 
to break into the kernel probably want to disable the pagetable 
dumper in debugfs, that will show the exact location of the kernel 
image.

(Btw., please also check that unprivileged users cannot read that 
file.)

Thanks,

	Ingo
--
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/