linux-kernel - Re: Kernel build error on BTFIDS vmlinux

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]

Message-ID: <f03e0fec4b29afe24a7a13c43de23e6db6dfce23.camel@klomp.org>
Date:   Thu, 20 Aug 2020 00:00:09 +0200
From:   Mark Wielaard <mark@...mp.org>
To:     Jiri Olsa <jolsa@...hat.com>, Nick Clifton <nickc@...hat.com>
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>, sdf@...gle.com,
        andriin@...com
Subject: Re: Kernel build error on BTFIDS vmlinux

Hi,

On Wed, 2020-08-19 at 19:18 +0200, Jiri Olsa wrote:
> On Wed, Aug 19, 2020 at 04:34:30PM +0100, Nick Clifton wrote:
> > > So it would be nice if binutils ld could also be fixed to write out
> > > compressed sections with the correct alignment.
> > 
> > OK, I will look into doing this.
> > 
> > By any chance is there a small test case that you are using to check
> > this behaviour ?   If so, please may I have a copy for myself ?
> 
> so when I take empty object and compile like:
> 
>   $ echo 'int main(int argc, char **argv) { return 0; }' | gcc -c -o ex.o -g -gz=zlib -x c -
>   $ ld -o ex --compress-debug-sections=zlib ex.o
> 
> then there's .debug_info section that shows sh_addralign = 1

Specifically, if you extend the example code a bit so that it has a
couple more interesting compressed .debug sections (like in an vmlinux
image) you'll see, eu-readelf -Sz:

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
     [Compression  Size     Al]

[37] .debug_aranges       PROGBITS     0000000000000000 027ae9f0 0000b274  0 C      0   0 16
     [ELF ZLIB (1) 00028030 16]
[38] .debug_info          PROGBITS     0000000000000000 027b9c64 07b1fc3d  0 C      0   0  1
     [ELF ZLIB (1) 0cb137ad  1]
[39] .debug_abbrev        PROGBITS     0000000000000000 0a2d98a1 00119647  0 C      0   0  1
     [ELF ZLIB (1) 0060811f  1]
[40] .debug_line          PROGBITS     0000000000000000 0a3f2ee8 007086ba  0 C      0   0  1
     [ELF ZLIB (1) 01557659  1]
[41] .debug_frame         PROGBITS     0000000000000000 0aafb5a8 000ab7ff  0 C      0   0  8
     [ELF ZLIB (1) 002a6bf8  8]
[42] .debug_str           PROGBITS     0000000000000000 0aba6da7 000f86e3  1 MSC    0   0  1
     [ELF ZLIB (1) 003a8a8e  1]
[43] .debug_loc           PROGBITS     0000000000000000 0ac9f48a 002e12bd  0 C      0   0  1
     [ELF ZLIB (1) 00e0c448  1]
[44] .debug_ranges        PROGBITS     0000000000000000 0af80750 001a9ec7  0 C      0   0 16
     [ELF ZLIB (1) 00e84b20 16]

Note that the sh_addralign of the sections is set to the same valie as
ch_addralign. That is the alignment of the decompressed data, what
sh_addralign would have been if it wasn't a compressed section.

The sh_addralign of a compressed section however should be equal to
alignment for the datastructure inside it, either 4, for 32bit:

typedef struct
{
  Elf32_Word    ch_type;        /* Compression format.  */
  Elf32_Word    ch_size;        /* Uncompressed data size.  */
  Elf32_Word    ch_addralign;   /* Uncompressed data alignment.  */
} Elf32_Chdr;

or 8, for 64bit:

typedef struct
{
  Elf64_Word    ch_type;        /* Compression format.  */
  Elf64_Word    ch_reserved;
  Elf64_Xword   ch_size;        /* Uncompressed data size.  */
  Elf64_Xword   ch_addralign;   /* Uncompressed data alignment.  */
} Elf64_Chdr;

At least, that is what elfutils libelf expects. And which I believe is
what the ELF spec implies when it says:

   The sh_size and sh_addralign fields of the section header for a
   compressed section reflect the requirements of the compressed
   section.  The ch_size and ch_addralign fields in the compression
   header provide the corresponding values for the uncompressed data,
   thereby supplying the values that sh_size and sh_addralign would
   have had if the section had not been compressed.

> after I open the 'ex' obejct with elf_begin and iterate sections
> 
> according to Mark that should be 8 (on 64 bits)
> 
> when I change it to 8, the elf_update call won't fail for me
> on that elf file

Right, I have a patch that fixes it up in libelf, see attached.
That should make things work without needing a workaround. But of
course I just posted it and it isn't even upstream yet. So for now the
workaround will be needed and it would be nice if binutils ld could
also be fixed to set the sh_addralign field correctly.

Cheers,

Mark

View attachment "0001-libelf-Fixup-SHF_COMPRESSED-sh_addralign-in-elf_upda.patch" of type "text/x-patch" (2712 bytes)