[PATCH] Add ELF note with Linux version

[PATCH] Add ELF note with Linux version

[Bernhard Walle]

This patch adds version information to the ELF kernel file. Together
with the bzImage version information, this allows distributions to
identify the kernel version based on the file name.


Signed-off-by: Dan Aloni <da-x@monatomic.org>
Signed-off-by: Bernhard Walle <bwalle@suse.de>

---
 include/linux/elfnote.h |    9 +++++++++
 init/version.c          |    3 +++
 2 files changed, 12 insertions(+)

--- a/include/linux/elfnote.h
+++ b/include/linux/elfnote.h
@@ -93,6 +93,15 @@
 
 #define ELFNOTE32(name, type, desc) ELFNOTE(32, name, type, desc)
 #define ELFNOTE64(name, type, desc) ELFNOTE(64, name, type, desc)
+
+#ifdef CONFIG_64BIT
+#define ELFNOTE_C(params...) ELFNOTE64(params)
+#else
+#define ELFNOTE_C(params...) ELFNOTE32(params)
+#endif
+
 #endif	/* __ASSEMBLER__ */
 
+#define LINUX_ELFNOTE_UTS_RELEASE    0
+
 #endif /* _LINUX_ELFNOTE_H */
--- a/init/version.c
+++ b/init/version.c
@@ -11,6 +11,7 @@
 #include <linux/uts.h>
 #include <linux/utsname.h>
 #include <linux/utsrelease.h>
+#include <linux/elfnote.h>
 #include <linux/version.h>
 
 #define version(a) Version_ ## a
@@ -42,3 +43,5 @@ const char linux_proc_banner[] =
 	"%s version %s"
 	" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
 	" (" LINUX_COMPILER ") %s\n";
+
+ELFNOTE_C("LINUX", LINUX_ELFNOTE_UTS_RELEASE, UTS_RELEASE);

Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Bernhard Walle wrote:
> This patch adds version information to the ELF kernel file. Together
> with the bzImage version information, this allows distributions to
> identify the kernel version based on the file name.
>   

Seems reasonable to me, but I think the macro could be just called
"ELFNOTE".

    J

Re: [PATCH] Add ELF note with Linux version

[Andrew Morton]

On Thu, 06 Sep 2007 11:36:21 +0100
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Bernhard Walle wrote:
> > This patch adds version information to the ELF kernel file. Together
> > with the bzImage version information, this allows distributions to
> > identify the kernel version based on the file name.
> >   
> 
> Seems reasonable to me, but I think the macro could be just called
> "ELFNOTE".
> 

You removed Bernhard from the cc list.

I'd like to know a little bit more about why this is needed, how it will be
used, etc.  And given that this feature is intended to improve life for
distributors, it would be nice to get some feedback from the appropriate
persons.

So could you please redo the patch as Jermey suggests (if you agree),
revamp the description and then cc suitable people at suitable distros so
we can get their input?

Thanks.

Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> On Thu, 06 Sep 2007 11:36:21 +0100
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
>   
>> Bernhard Walle wrote:
>>     
>>> This patch adds version information to the ELF kernel file. Together
>>> with the bzImage version information, this allows distributions to
>>> identify the kernel version based on the file name.
>>>   
>>>       
>> Seems reasonable to me, but I think the macro could be just called
>> "ELFNOTE".
>>
>>     
>
> You removed Bernhard from the cc list.
>   

Didn't mean to... Oh, he has a "mail-followup-to" header which doesn't
include himself...

> I'd like to know a little bit more about why this is needed, how it will be
> used, etc.  And given that this feature is intended to improve life for
> distributors, it would be nice to get some feedback from the appropriate
> persons.

Hm, yes.  ELF notes don't appear in the bzImage, since it isn't an ELF
file, so perhaps this doesn't satisfy the requirement.  It would help to
have more detail.

    J

Re: [PATCH] Add ELF note with Linux version

[Sam Ravnborg]

On Thu, Sep 13, 2007 at 02:42:28PM -0700, Andrew Morton wrote:
> On Thu, 06 Sep 2007 11:36:21 +0100
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> 
> > Bernhard Walle wrote:
> > > This patch adds version information to the ELF kernel file. Together
> > > with the bzImage version information, this allows distributions to
> > > identify the kernel version based on the file name.
> > >   
> > 
> > Seems reasonable to me, but I think the macro could be just called
> > "ELFNOTE".
> > 
> 
> You removed Bernhard from the cc list.
> 
> I'd like to know a little bit more about why this is needed, how it will be
> used, etc.  And given that this feature is intended to improve life for
> distributors, it would be nice to get some feedback from the appropriate
> persons.
> 
> So could you please redo the patch as Jermey suggests (if you agree),
> revamp the description and then cc suitable people at suitable distros so
> we can get their input?

I would rather see allt this ELFNOTE stuff reverted.
It causes troubles for several archs and is at the moment
being discussed at arm-kernel for example.

Having it reverted and then applied when it is ready for all archs would
be preferred.

On top of this I never understood the actual purpose of it...

	Sam

Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
> I would rather see allt this ELFNOTE stuff reverted.
> It causes troubles for several archs and is at the moment
> being discussed at arm-kernel for example.
>
> Having it reverted and then applied when it is ready for all archs would
> be preferred.
>   

What problems does it cause on other archs?  It should be
cross-architecture.

> On top of this I never understood the actual purpose of it...

It was originally there to put ELF notes into the vdso objects.  I'm
using it to create notes in vmlinux for Xen, and apparently people are
using it to put other metadata into their kernel images.

    J

Re: [PATCH] Add ELF note with Linux version

[Sam Ravnborg]

On Thu, Sep 13, 2007 at 03:44:13PM -0700, Jeremy Fitzhardinge wrote:
> Sam Ravnborg wrote:
> > I would rather see allt this ELFNOTE stuff reverted.
> > It causes troubles for several archs and is at the moment
> > being discussed at arm-kernel for example.
> >
> > Having it reverted and then applied when it is ready for all archs would
> > be preferred.
> >   
> 
> What problems does it cause on other archs?  It should be
> cross-architecture.
> 
> > On top of this I never understood the actual purpose of it...
> 
> It was originally there to put ELF notes into the vdso objects.  I'm
> using it to create notes in vmlinux for Xen, and apparently people are
> using it to put other metadata into their kernel images.
>From a post on arm-kernel:

> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
> a 3.1 Gbytes Image file.

This seems outright silly.
Either we should revert the notes changes or someone caring about it 
should sweep all archs and make sure it does not hurt there.

	Sam

Re: [PATCH] Add ELF note with Linux version

[Bernhard Walle]

* Jeremy Fitzhardinge <jeremy@goop.org> [2007-09-13 23:56]:
> 
> > I'd like to know a little bit more about why this is needed, how it will be
> > used, etc.  And given that this feature is intended to improve life for
> > distributors, it would be nice to get some feedback from the appropriate
> > persons.
> 
> Hm, yes.  ELF notes don't appear in the bzImage, since it isn't an ELF
> file, so perhaps this doesn't satisfy the requirement.  It would help to
> have more detail.

the bzImage already contains the version (and much more, e.g. if the
kernel is relocatable, the command line length it accepts). See
Documentation/i386/boot.txt.



Thanks,
   Bernhard

Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
> On Thu, Sep 13, 2007 at 03:44:13PM -0700, Jeremy Fitzhardinge wrote:
>   
>> It was originally there to put ELF notes into the vdso objects.  I'm
>> using it to create notes in vmlinux for Xen, and apparently people are
>> using it to put other metadata into their kernel images.
>>     
> From a post on arm-kernel:
>
>   
>> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
>> a 3.1 Gbytes Image file.
>>     
>
> This seems outright silly.
> Either we should revert the notes changes or someone caring about it 
> should sweep all archs and make sure it does not hurt there.

Hm, sounds like yet another binutils bug; unfortunately common when ELF
notes are about.  Was there any further effort to isolate what was
causing the problem?

    J

Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Bernhard Walle wrote:
> * Jeremy Fitzhardinge <jeremy@goop.org> [2007-09-13 23:56]:
>   
>>> I'd like to know a little bit more about why this is needed, how it will be
>>> used, etc.  And given that this feature is intended to improve life for
>>> distributors, it would be nice to get some feedback from the appropriate
>>> persons.
>>>       
>> Hm, yes.  ELF notes don't appear in the bzImage, since it isn't an ELF
>> file, so perhaps this doesn't satisfy the requirement.  It would help to
>> have more detail.
>>     
>
> the bzImage already contains the version (and much more, e.g. if the
> kernel is relocatable, the command line length it accepts). See
> Documentation/i386/boot.txt.
>   

Yes, I'm familiar with that.  I'm wondering what end result you're
trying to achieve though.  What's the specific problem?

    J

Re: [PATCH] Add ELF note with Linux version

[Sam Ravnborg]

> > This seems outright silly.
> > Either we should revert the notes changes or someone caring about it 
> > should sweep all archs and make sure it does not hurt there.
> 
> Hm, sounds like yet another binutils bug; unfortunately common when ELF
> notes are about.  Was there any further effort to isolate what was
> causing the problem?

Lennart posted this:
An ARM vmlinux kernel image built with pre-build-id binutils has:

        Program Header:
            LOAD off    0x00008000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
                 filesz 0x002e503c memsz 0x003032c0 flags rwx
        private flags = 4000002: [Version4 EABI] [has entry point]


Whereas a build-id binutils-built vmlinux kernel image ends up with:

        Program Header:
            LOAD off    0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**15
                 filesz 0x00000024 memsz 0x00000024 flags r--
            LOAD off    0x00010000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
                 filesz 0x002e503c memsz 0x003032c0 flags rwx
            NOTE off    0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**2
                 filesz 0x00000024 memsz 0x00000024 flags r--
        private flags = 4000002: [Version4 EABI] [has entry point]


The .note.gnu.build-id section causes objcopy to produce a 3G+
Image file, breaking the build.


Samuel Ortiz posted following patch:
> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
> a 3.1 Gbytes Image file. Adding a note section fixes the problem.
> 
> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> 
> ---
>  arch/arm/kernel/vmlinux.lds.S |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6.22/arch/arm/kernel/vmlinux.lds.S
> ===================================================================
> --- linux-2.6.22.orig/arch/arm/kernel/vmlinux.lds.S   2007-09-11 18:32:29.000000000 +0200
> +++ linux-2.6.22/arch/arm/kernel/vmlinux.lds.S        2007-09-11 18:33:42.000000000 +0200
> @@ -94,6 +94,7 @@
>                       TEXT_TEXT
>                       SCHED_TEXT
>                       LOCK_TEXT
> +                     *(.note.*)
>  #ifdef CONFIG_MMU
>                       *(.fixup)
>  #endif


I cannot see why this should fix it since the patch does
not discard the section. Maybe the inclusion of the section in
some oter section does some good.

Anyway the original submitter of the build-id should have identified such
issues and fixed all archs.

And I still do not get exactly what problem the note section solves when
included in vmlinux....

	Sam

Re: [PATCH] Add ELF note with Linux version

[Roland McGrath]

The right fix for the linker script is to use the NOTES macro after RODATA.
I'm pretty sure this has been posted before.  Each arch's vmlinux.lds.S
needs that change, but the details vary if it uses an explicit PHDRS.


Thanks,
Roland

Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
>>> This seems outright silly.
>>> Either we should revert the notes changes or someone caring about it 
>>> should sweep all archs and make sure it does not hurt there.
>>>       
>> Hm, sounds like yet another binutils bug; unfortunately common when ELF
>> notes are about.  Was there any further effort to isolate what was
>> causing the problem?
>>     
>
> Lennart posted this:
> An ARM vmlinux kernel image built with pre-build-id binutils has:
>
>         Program Header:
>             LOAD off    0x00008000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
>                  filesz 0x002e503c memsz 0x003032c0 flags rwx
>         private flags = 4000002: [Version4 EABI] [has entry point]
>
>
> Whereas a build-id binutils-built vmlinux kernel image ends up with:
>
>         Program Header:
>             LOAD off    0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**15
>                  filesz 0x00000024 memsz 0x00000024 flags r--
>             LOAD off    0x00010000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
>                  filesz 0x002e503c memsz 0x003032c0 flags rwx
>             NOTE off    0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**2
>                  filesz 0x00000024 memsz 0x00000024 flags r--
>         private flags = 4000002: [Version4 EABI] [has entry point]
>
>
> The .note.gnu.build-id section causes objcopy to produce a 3G+
> Image file, breaking the build.
>   

Hm, these phdrs seem OK though; I don't see any ~3Gish numbers here, so
it looks like objcopy is just going off into the weeds. 

I don't know how ARM images are built, but I would guess that something
is trying to make the file large enough to accomodate a 3Gish kernel
virtual address address which hasn't being appropriately phys-ized.  It
may be more a linker script bug than an inherent problem with either
notes or build-id themselves.

> Samuel Ortiz posted following patch:
>   
>> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
>> a 3.1 Gbytes Image file. Adding a note section fixes the problem.
>>
>> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
>> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
>> Cc: Sam Ravnborg <sam@ravnborg.org>
>>
>> ---
>>  arch/arm/kernel/vmlinux.lds.S |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> Index: linux-2.6.22/arch/arm/kernel/vmlinux.lds.S
>> ===================================================================
>> --- linux-2.6.22.orig/arch/arm/kernel/vmlinux.lds.S   2007-09-11 18:32:29.000000000 +0200
>> +++ linux-2.6.22/arch/arm/kernel/vmlinux.lds.S        2007-09-11 18:33:42.000000000 +0200
>> @@ -94,6 +94,7 @@
>>                       TEXT_TEXT
>>                       SCHED_TEXT
>>                       LOCK_TEXT
>> +                     *(.note.*)
>>  #ifdef CONFIG_MMU
>>                       *(.fixup)
>>  #endif
>>     
>
>
> I cannot see why this should fix it since the patch does
> not discard the section. Maybe the inclusion of the section in
> some oter section does some good.
>   

Yes, binutils can be pretty fragile with notes about.  In this case it
seems to be a specific problem with build-id; I'm not really sure what
build-id actually does.

Though if my theory above is true, it may end up properly assigning a
value to a symbol
by putting it into the right section.  Or something.
> Anyway the original submitter of the build-id should have identified such
> issues and fixed all archs.
>
> And I still do not get exactly what problem the note section solves when
> included in vmlinux....

The Note section is supposed to be a general extensible way of adding
metadata to an object file, either for a linker or a loader.  There's no
inherent connection between notes and build-id (other than build-id is
one of the users of notes, I suppose).

    J

Re: [PATCH] Add ELF note with Linux version

[Roland McGrath]

> Yes, binutils can be pretty fragile with notes about.  In this case it
> seems to be a specific problem with build-id; I'm not really sure what
> build-id actually does.

The thing about the build ID section that brings up issues with linking is
that it is a SHF_ALLOC, SHT_NOTE section.  As you mentioned, this is a
general, straightforward, and well-defined thing in ELF.  But in practice,
there were not previously SHF_ALLOC note sections used with custom linker
scripts like the kernel's.  (They are used every day in normal executables
and DSOs, but those don't use custom linker scripts.)


Thanks,
Roland