linux-kernel - Re: [RFC PATCH 7/8] ARM: vmlinux.lds: Setup physical load address not virtual

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-next>] [day] [month] [year] [list]

Date:	Mon, 18 Jun 2012 15:02:53 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Michal Simek <monstr@...str.eu>
cc:	linux-kernel@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Marc Zyngier <marc.zyngier@....com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Will Deacon <will.deacon@....com>,
	Rob Herring <rob.herring@...xeda.com>,
	linux-arm-kernel@...ts.infradead.org,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Peter Crosthwaite <peter.crosthwaite@...alogix.com>
Subject: Re: [RFC PATCH 7/8] ARM: vmlinux.lds: Setup physical load address
 not virtual

On Mon, 18 Jun 2012, Michal Simek wrote:

> 2012/6/18 Nicolas Pitre <nicolas.pitre@...aro.org>
> 
> > On Mon, 18 Jun 2012, Michal Simek wrote:
> >
> > > Setup correct virtual and physical address in ELF LOAD section.
> >
> > We are moving to a single kernel binary for multiple targets, including
> > targets with different physical load addresses.  The kernel code figures
> > out at run time what the actual physical address is when
> > CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days.  In
> > other words, we don't know the physical offset at build time in that
> > case and CONFIG_PHYS_OFFSET is simply not defined.
> >
> 
> ok. good to know and nice features. In that case I expect that you are 
> using any binary format and you copy it to memory and run it. Code 
> find out where it runs and based on that setup things.

Exact.

> (BTW: This is very interesting for me to implement it on Microblaze. Can
> you point me to that kernel code part? or any doc?)

You could have a look at https://wiki.ubuntu.com/Specs/ARMSingleKernel, 
especially the section "Optimized virt_to_phys() with a runtime 
determined PHYS_OFFSET".

Then the following commits should be of interest:

72a20e22f4 "ARM: P2V: eliminate head.S use of PHYS_OFFSET for !XIP_KERNEL"

dc21af99fa "ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching"

> But can you do it with elf?

No.

> Please correct me if I am wrong IRC ARM Qemu uses zImage but it is no
> problem to use elf file. For this case
> Qemu elf loader also uses physical addresses from ELF and also entry point.

If you want to use the ELF image, then you need to hardcode the physical 
memory location in its header, and that's something we want to get away 
from because it prevents a single kernel binary image from being used on 
different targets with different memory layouts.  Same issue with 
u-Boot's legacy uImage format.

> I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf
> entry point for this case?

For the kernel image itself it is the kernel virtual address.

For the relocatable zImage decompressor wrapper it is 0.


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