xen (multiboot) binary gets corrupted ELF notes

xen (multiboot) binary gets corrupted ELF notes

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

Hi,

I'm getting some ELF note issues on multiboot binary
specifically:
xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=f7d2c37a4ad599b268f2f2d94bff3776d12649b3, bad note description size 0xc0010001, stripped

readelf additionally says:

    Displaying notes found in: .note
      Owner                Data size 	Description
      GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
        Build ID: c5825a0d08edc4d11b1138fedca6b14ce8ba7302
      (NONE)               0x00000004	Unknown note type: (0x00000020)
       description data: 05 00 00 00 
    readelf: xen/xen: Warning: note with invalid namesz and/or descsz found at offset 0x34
    readelf: xen/xen: Warning:  type: 0x4, namesize: 0x00554e47, descsize: 0xc0010001, alignment: 4

Grub doesn't care, but launching such xen with kexec doesn't work.

Initially found when booting Xen via Heads: https://openqa.qubes-os.org/tests/60151#step/install_startup/11

Andy says:
> yeah, I've seen the same on XTF
> binutil's recent elf notes for CET compatibility use an unsigned long
> so they're not compatible when we build as 64bit and then re-package as 32
> I think we need to strip all elf notes in mkelf32

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: xen (multiboot) binary gets corrupted ELF notes

[Jan Beulich]

On 13.02.2023 12:14, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I'm getting some ELF note issues on multiboot binary
> specifically:
> xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=f7d2c37a4ad599b268f2f2d94bff3776d12649b3, bad note description size 0xc0010001, stripped
> 
> readelf additionally says:
> 
>     Displaying notes found in: .note
>       Owner                Data size 	Description
>       GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
>         Build ID: c5825a0d08edc4d11b1138fedca6b14ce8ba7302
>       (NONE)               0x00000004	Unknown note type: (0x00000020)
>        description data: 05 00 00 00 
>     readelf: xen/xen: Warning: note with invalid namesz and/or descsz found at offset 0x34
>     readelf: xen/xen: Warning:  type: 0x4, namesize: 0x00554e47, descsize: 0xc0010001, alignment: 4
> 
> Grub doesn't care, but launching such xen with kexec doesn't work.
> 
> Initially found when booting Xen via Heads: https://openqa.qubes-os.org/tests/60151#step/install_startup/11
> 
> Andy says:
>> yeah, I've seen the same on XTF
>> binutil's recent elf notes for CET compatibility use an unsigned long
>> so they're not compatible when we build as 64bit and then re-package as 32
>> I think we need to strip all elf notes in mkelf32

Instead of complicating mkelf32 (we want to retain at least the build-id
note, after all, and for PVH_GUEST builds also .note.Xen) why don't we
discard the unwanted/unneeded notes then from the linker script, just
like we already do for xen.efi?

Jan

Re: xen (multiboot) binary gets corrupted ELF notes

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]

On Mon, Feb 13, 2023 at 01:53:21PM +0100, Jan Beulich wrote:
> On 13.02.2023 12:14, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > I'm getting some ELF note issues on multiboot binary
> > specifically:
> > xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=f7d2c37a4ad599b268f2f2d94bff3776d12649b3, bad note description size 0xc0010001, stripped
> > 
> > readelf additionally says:
> > 
> >     Displaying notes found in: .note
> >       Owner                Data size 	Description
> >       GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
> >         Build ID: c5825a0d08edc4d11b1138fedca6b14ce8ba7302
> >       (NONE)               0x00000004	Unknown note type: (0x00000020)
> >        description data: 05 00 00 00 
> >     readelf: xen/xen: Warning: note with invalid namesz and/or descsz found at offset 0x34
> >     readelf: xen/xen: Warning:  type: 0x4, namesize: 0x00554e47, descsize: 0xc0010001, alignment: 4
> > 
> > Grub doesn't care, but launching such xen with kexec doesn't work.
> > 
> > Initially found when booting Xen via Heads: https://openqa.qubes-os.org/tests/60151#step/install_startup/11
> > 
> > Andy says:
> >> yeah, I've seen the same on XTF
> >> binutil's recent elf notes for CET compatibility use an unsigned long
> >> so they're not compatible when we build as 64bit and then re-package as 32
> >> I think we need to strip all elf notes in mkelf32
> 
> Instead of complicating mkelf32 (we want to retain at least the build-id
> note, after all, and for PVH_GUEST builds also .note.Xen) why don't we
> discard the unwanted/unneeded notes then from the linker script, just
> like we already do for xen.efi?

Ok, this seems to help:

---8<----
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 8930e14fc40e..f0831bd677e7 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -192,13 +192,6 @@ SECTIONS
 #endif
 #endif
 
-#ifndef EFI
-  /* Retain these just for the purpose of possible analysis tools. */
-  DECL_SECTION(.note) {
-       *(.note.*)
-  } PHDR(note) PHDR(text)
-#endif
-
   _erodata = .;
 
   . = ALIGN(SECTION_ALIGN);
---8<---

The comment suggests some notes could be useful, but given they are
broken anyway and nobody complained so far, maybe not really?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: xen (multiboot) binary gets corrupted ELF notes

[Jan Beulich]

On 13.02.2023 15:12, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 13, 2023 at 01:53:21PM +0100, Jan Beulich wrote:
>> On 13.02.2023 12:14, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I'm getting some ELF note issues on multiboot binary
>>> specifically:
>>> xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=f7d2c37a4ad599b268f2f2d94bff3776d12649b3, bad note description size 0xc0010001, stripped
>>>
>>> readelf additionally says:
>>>
>>>     Displaying notes found in: .note
>>>       Owner                Data size 	Description
>>>       GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
>>>         Build ID: c5825a0d08edc4d11b1138fedca6b14ce8ba7302
>>>       (NONE)               0x00000004	Unknown note type: (0x00000020)
>>>        description data: 05 00 00 00 
>>>     readelf: xen/xen: Warning: note with invalid namesz and/or descsz found at offset 0x34
>>>     readelf: xen/xen: Warning:  type: 0x4, namesize: 0x00554e47, descsize: 0xc0010001, alignment: 4
>>>
>>> Grub doesn't care, but launching such xen with kexec doesn't work.
>>>
>>> Initially found when booting Xen via Heads: https://openqa.qubes-os.org/tests/60151#step/install_startup/11
>>>
>>> Andy says:
>>>> yeah, I've seen the same on XTF
>>>> binutil's recent elf notes for CET compatibility use an unsigned long
>>>> so they're not compatible when we build as 64bit and then re-package as 32
>>>> I think we need to strip all elf notes in mkelf32
>>
>> Instead of complicating mkelf32 (we want to retain at least the build-id
>> note, after all, and for PVH_GUEST builds also .note.Xen) why don't we
>> discard the unwanted/unneeded notes then from the linker script, just
>> like we already do for xen.efi?
> 
> Ok, this seems to help:
> 
> ---8<----
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 8930e14fc40e..f0831bd677e7 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -192,13 +192,6 @@ SECTIONS
>  #endif
>  #endif
>  
> -#ifndef EFI
> -  /* Retain these just for the purpose of possible analysis tools. */
> -  DECL_SECTION(.note) {
> -       *(.note.*)
> -  } PHDR(note) PHDR(text)
> -#endif
> -
>    _erodata = .;
>  
>    . = ALIGN(SECTION_ALIGN);
> ---8<---
> 
> The comment suggests some notes could be useful, but given they are
> broken anyway and nobody complained so far, maybe not really?

Well, much depends on those unspecified analysis tools.

Jan