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]
Message-ID: <alpine.LSU.2.11.2009142337530.1550@eggly.anvils>
Date:   Tue, 15 Sep 2020 00:50:54 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Static call dependency on libelf version?

This is just an FYI written from a position of ignorance: I may
have got it wrong, and my build environment too piecemeal to matter
to anyone else; but what I saw was weird enough to be worth mentioning,
in case it saves someone some time.

I usually build and test on mmotm weekly rather linux-next daily.
No problem with 5.9-rc3-mm1 from 2020-09-04, nor with 5.9-rc5, but
(on two machines) 5.9-rc5-mm1 from 2020-09-13 could not link vmlinux:

  AR      init/built-in.a
  LD      vmlinux.o
ld: warning: init/main.o has a corrupt section with a size (7472747368732e00) larger than the file size
ld: warning: init/main.o has a corrupt section with a size (7472747368732e00) larger than the file size
ld: warning: init/main.o has a corrupt section with a size (7472747368732e00) larger than the file size
ld: warning: init/main.o has a corrupt section with a size (7472747368732e00) larger than the file size
ld: init/built-in.a: member init/main.o in archive is not an object
make[1]: *** [vmlinux] Error 1
make: *** [__sub-make] Error 2

On the third machine, a more recent installation, but using the same
gcc and the same binutils, I could build the same config successfully.
init/main.o was the same size on each (49216 bytes), but diff of hd
of the good against the bad showed:

2702,2709c2702,2709
< 00bfc0 000001db 00000001 00000003 00000000  >................<
< 00bfd0 00000000 00000000 0000b316 00000000  >................<
< 00bfe0 00000018 00000000 00000000 00000000  >................<
< 00bff0 00000001 00000000 00000008 00000000  >................<
< 00c000 000001ee 00000004 00000040 00000000  >........@.......<
< 00c010 00000000 00000000 0000b330 00000000  >........0.......<
< 00c020 00000090 00000000 0000002d 00000030  >........-...0...<
< 00c030 00000008 00000000 00000018 00000000  >................<
---
> 00bfc0 00000000 00000000 000001f1 00000000  >................<
> 00bfd0 79732e00 6261746d 74732e00 62617472  >..symtab..strtab<
> 00bfe0 68732e00 74727473 2e006261 616c6572  >..shstrtab..rela<
> 00bff0 7865742e 722e0074 2e616c65 61746164  >.text..rela.data<
> 00c000 73622e00 722e0073 5f616c65 6172745f  >..bss..rela__tra<
> 00c010 6f706563 73746e69 7274705f 722e0073  >cepoints_ptrs..r<
> 00c020 2e616c65 74617473 635f6369 2e6c6c61  >ela.static_call.<
> 00c030 74786574 65722e00 692e616c 2e74696e  >text..rela.init.<

and 217 other .os in the build tree also "corrupted".

CONFIG_HAVE_STATIC_CALL=y
CONFIG_HAVE_STATIC_CALL_INLINE=y
stand out as new in the .config for 5.9-rc5-mm1, and references
to objtool in static_call.h and static_call_types.h took me to
tools/objtool/Makefile, with its use of libelf.

I've copied over files of the newer libelf (0.168) to the failing
machines, which are now building the 5.9-rc5-mm1 vmlinux correctly.

It looks as if CONFIG_HAVE_STATIC_CALL=y depends on a newer libelf
than I had before (0.155), and should either insist on a minimum
version, or else be adjusted to work with older versions.

Hope this helps,
Hugh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ