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, 19 Feb 2016 12:57:43 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Arnd Bergmann <arnd@...db.de>,
	Chris Brandt <Chris.Brandt@...esas.com>,
	Jon Medhurst <tixy@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On Fri, 19 Feb 2016, Russell King - ARM Linux wrote:

> ARM_PATCH_PHYS_VIRT exists to support an init-time decided phys offset,
> and it supports this by modifying each location that the phys offset
> is used.  It determines this by looking at the location that the early
> init code is executing, and masking the PC with a value that has been
> carefully crafted to fit 99% of the existing platforms.
> 
> One of the side effects of ARM_PATCH_PHYS_VIRT is that we hide the
> translation from the compiler, so the compiler is unable to optimise
> things like virt_to_phys(phys_to_virt(x)) to just 'x' (and yes, such
> things do happen.)
> 
> PHYS_OFFSET exists to cater for the case where ARM_PATCH_PHYS_VIRT is
> disabled, because either ARM_PATCH_PHYS_VIRT does not work for the
> platform, or the platform has special requirements and/or requires
> better performance.  It switches back to the pre-ARM_PATCH_PHYS_VIRT
> situation where the PHYS_OFFSET is a compile time constant.
> 
> Obviously, making PHYS_OFFSET a runtime variable is basically what
> ARM_PATCH_PHYS_VIRT is doing.  That does not help these cases though,
> because the problem cases are not whether it's a runtime variable or
> not, it's how to arrive at the value for it in the first place.

I think what Chris was suggesting is to have the same functionality as 
PATCH_PHYS_VIRT i.e. determining phys offset at run time while being 
XIP.  In theory that could mean that the kernel binary becomes 
independent of the physical location in flash where it executes from.

Arriving at the value for phys offset could be done based on sp instead 
of pc.  That's assuming the bootloader did not clobber sp before calling 
into the kernel.

But this is rather fragile. And normally if you are interested in XIP, 
you certainly have a highly customized kernel config already anyway. And 
having a build-time constant PHYS_OFFSET is of course what performs 
best.


Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ