[PATCH] Fix ELF entry point (i386)

[PATCH] Fix ELF entry point (i386)

[Gerd Hoffmann]

  Hi,

Elf entry point is virtual address, not physical ...

please apply,

  Gerd

========================================================================
--- linux.o/arch/i386/kernel/vmlinux.lds.S	Tue Feb 21 18:36:00 2006
+++ linux/arch/i386/kernel/vmlinux.lds.S	Wed Feb 22 11:52:14 2006
@@ -10,7 +10,7 @@

 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
 OUTPUT_ARCH(i386)
-ENTRY(phys_startup_32)
+ENTRY(startup_32)
 jiffies = jiffies_64;
 SECTIONS
 {

Re: [PATCH] Fix ELF entry point (i386)

[Eric W. Biederman]

Gerd Hoffmann <kraxel@suse.de> writes:

>   Hi,
>
> Elf entry point is virtual address, not physical ...
>
> please apply,

NACK

We load the kernel at physical addresses and we enter
the kernel at a physical address.  Even the entry point
expects that.

Is there some reason you think the entry point is virtual?

Eric

Re: [PATCH] Fix ELF entry point (i386)

[Gerd Hoffmann]

Eric W. Biederman wrote:
> 
> We load the kernel at physical addresses and we enter
> the kernel at a physical address.  Even the entry point
> expects that.
> 
> Is there some reason you think the entry point is virtual?

Elf specs say so.  The paragraph in question mentions processes not OS
kernels though ...

cheers,

  Gerd

-- 
Gerd 'just married' Hoffmann <kraxel@suse.de>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg

Re: [PATCH] Fix ELF entry point (i386)

[Eric W. Biederman]

Gerd Hoffmann <kraxel@suse.de> writes:

> Eric W. Biederman wrote:
>> 
>> We load the kernel at physical addresses and we enter
>> the kernel at a physical address.  Even the entry point
>> expects that.
>> 
>> Is there some reason you think the entry point is virtual?
>
> Elf specs say so.  The paragraph in question mentions processes not OS
> kernels though ...

The ELF spec only defines how ELF is interpreted for processes running under
an OS if I remember correctly.  Stand-alone executable that run without an
OS (like an OS kernel) play be slightly different rules, and I don't know if
anyone has ever formalized them.  As a consequence those rules like vary
between bootloaders and between architectures.

Currently my assumptions are:

Standalone executables load at the physical not the virtual addresses.
Standalone executables start executing at a physical address and not at
a virtual address.

In most cases virtual==physical in ELF binaries.  Which if you are throwing
something quick together means they will work in either circumstance.  Also
it is unfortunate that ld currently emits relocations for absolute symbols
in ET_DYN executables.

Of practical consequence currently /sbin/kexec makes the assumptions I have
outlined above.  So if you change that you not be able to boot vmlinx with
/sbin/kexec.

Eric

Re: [PATCH] Fix ELF entry point (i386)

[Gerd Hoffmann]

> Currently my assumptions are:
> 
> Standalone executables load at the physical not the virtual addresses.
> Standalone executables start executing at a physical address and not at
> a virtual address.

Well, that is true for real hardware.  xen guest kernels are booted with
paging already enabled and thus the entry point is in virtual memory,
and I'm trying to figure how to handle that best (both for initial boot
and kexec).

xen uses a special xen header anyway to give the domain builder a hint
how the initial page tables should look like (they look simliar to what
head.S creates on real hardware).  That can also be used to figure the
correct virtual entry point from the physical one.  It probably even
makes more sense to do that (instead of writing the virtual address into
the entry point) as the xen domain builder doesn't look at the virtual
addresses in the ELF headers too.  It uses PAGE_OFFSET+paddr instead.
That keeps the differences between real and virtual hardware small ...

cheers,

  Gerd

-- 
Gerd 'just married' Hoffmann <kraxel@suse.de>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg

Re: [PATCH] Fix ELF entry point (i386)

[Eric W. Biederman]

Gerd Hoffmann <kraxel@suse.de> writes:

>> Currently my assumptions are:
>> 
>> Standalone executables load at the physical not the virtual addresses.
>> Standalone executables start executing at a physical address and not at
>> a virtual address.
>
> Well, that is true for real hardware.  xen guest kernels are booted with
> paging already enabled and thus the entry point is in virtual memory,
> and I'm trying to figure how to handle that best (both for initial boot
> and kexec).
>
> xen uses a special xen header anyway to give the domain builder a hint
> how the initial page tables should look like (they look simliar to what
> head.S creates on real hardware).  That can also be used to figure the
> correct virtual entry point from the physical one.  It probably even
> makes more sense to do that (instead of writing the virtual address into
> the entry point) as the xen domain builder doesn't look at the virtual
> addresses in the ELF headers too.  It uses PAGE_OFFSET+paddr instead.
> That keeps the differences between real and virtual hardware small ...

Ok. The unmerged Xen case.

I have some pending patches that make a bzImage a ET_DYN executable.
Would that be interesting to you?  Especially if that would just mean
your initial page tables got to set physical == virtual?

I believe Xen does expose the actual physical addresses to the guest.

Either that or this is a case where Xen probably needs to take a
different path in the build system.

Eric

Re: [PATCH] Fix ELF entry point (i386)

[Gerd Hoffmann]

Eric W. Biederman wrote:
> 
> Ok. The unmerged Xen case.
> 
> I have some pending patches that make a bzImage a ET_DYN executable.
> Would that be interesting to you?  Especially if that would just mean
> your initial page tables got to set physical == virtual?

i.e. you insert a additional state into the boot process which does the
relocation and page table setup?  URL would to the patch be nice, yes.
A paper (or at least a short outline how it works) even better ;)

> I believe Xen does expose the actual physical addresses to the guest.

Well, xen has two modes now:  One where the guest knows the machine
addresses and has to translate machine[1] <=> physical[2] addresses.
And one where xen does the translation transparantly.  The former
performs better, the later is easier to implement ;)

> Either that or this is a case where Xen probably needs to take a
> different path in the build system.

For the build system it shouldn't matter.  Ideally only the code
creating page tables has to care about that.  Right now xen creates
old-style ELF binaries (pre-kexec merge) with wrong paddr entries, but
that's fixable (have patches pending for xen).

Unlike real hardware xen virtual machines run with paging enabled all
the time, so you can't just turn off paging to get a identity (phys ==
virt) mapping.  That makes things a bit harder sometimes.

  Gerd

[1] machine address  == physical address of the real hardware.
[2] physical address == physical address of the virtual machine.

-- 
Gerd 'just married' Hoffmann <kraxel@suse.de>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg

Re: [PATCH] Fix ELF entry point (i386)

[Gerd Hoffmann]

  Hi,

> I have some pending patches that make a bzImage a ET_DYN executable.
> Would that be interesting to you?  Especially if that would just mean
> your initial page tables got to set physical == virtual?

ping, do you have a url to the patches for me?

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
Erst mal heiraten, ein, zwei Kinder, und wenn alles läuft
geh' ich nach drei Jahren mit der Familie an die Börse.
http://www.suse.de/~kraxel/julika-dora.jpeg