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:	Thu, 26 May 2011 16:01:21 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Dan Rosenberg <drosenberg@...curity.com>
Cc:	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>,
	Valdis.Kletnieks@...edu, Ingo Molnar <mingo@...e.hu>,
	pageexec@...email.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot

On Tue, May 24, 2011 at 04:31:45PM -0400, Dan Rosenberg wrote:

[..]
>  ==============================================================
>  
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 880fcb6..999ea82 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1548,8 +1548,8 @@ config PHYSICAL_START
>  	  If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
>  	  bzImage will decompress itself to above physical address and
>  	  run from there. Otherwise, bzImage will run from the address where
> -	  it has been loaded by the boot loader and will ignore above physical
> -	  address.
> +	  it has been loaded by the boot loader, using the above physical
> +	  address as a lower bound.
>  
>  	  In normal kdump cases one does not have to set/change this option
>  	  as now bzImage can be compiled as a completely relocatable image
> @@ -1595,7 +1595,31 @@ config RELOCATABLE
>  
>  	  Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
>  	  it has been loaded at and the compile time physical address
> -	  (CONFIG_PHYSICAL_START) is ignored.
> +	  (CONFIG_PHYSICAL_START) is solely used as a lower bound.
> +

This does not sound too good. Overloading the definition of PHYSICAL_START
with minimum address. The very definition of relocatable kernel is that
it should be able to run from the physical address it has been loaded
at (subjected to alignment constraints).

So I don't think overloading CONFIG_PHYSICAL_START definition is a good
idea. In fact there is no reason that why kdump kernels should not run
and boot below 16MB. So limiting those kernels to not load and run
below 16MB is does not sound like good option to me.

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.

Thanks
Vivek
--
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