Bug 2044491 - annocheck FAIL: bind-now test because not linked with -Wl,-z,now (golist on aarch64 and x86_64)
Summary: annocheck FAIL: bind-now test because not linked with -Wl,-z,now (golist on a...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: go-rpm-macros
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: David Benoit
QA Contact: Edjunior Barbosa Machado
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-24 17:06 UTC by Edjunior Barbosa Machado
Modified: 2023-07-24 12:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-24 07:28:28 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
annocheck output (14.13 KB, text/plain)
2022-01-24 17:06 UTC, Edjunior Barbosa Machado
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-109424 0 None None None 2022-01-24 17:13:55 UTC

Description Edjunior Barbosa Machado 2022-01-24 17:06:53 UTC
Created attachment 1853117 [details]
annocheck output

Description of problem:
Latest go-rpm-macros-3.0.9-9.el9 build fails on annocheck test, part of rhel-9.0 rpminspect static analysis, with the following:

(...)
annocheck: Version 10.44.
Hardened: /usr/libexec/go-rpm-macros/golist: PASS: pie test 
Hardened: /usr/libexec/go-rpm-macros/golist: PASS: writable-got test 
Hardened: /usr/libexec/go-rpm-macros/golist: PASS: dynamic-segment test 
Hardened: /usr/libexec/go-rpm-macros/golist: FAIL: bind-now test because not linked with -Wl,-z,now 
Hardened: /usr/libexec/go-rpm-macros/golist: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-bind-now.html
(...)

The test fails only on aarch64 and x86_64 - it passes on s390x and ppc64le.

Version-Release number of selected component (if applicable):
go-rpm-macros-3.0.9-9.el9

Comment 1 Nick Clifton 2022-02-01 09:27:25 UTC
This is very strange.  Annocheck does appear to be correct in its issuing 
of a FAIL result.  For example looking at the dynamic information for the 
ppc64le version of golist shows:

  % readelf -d usr.ppc64le/libexec.ro-rpm-macros/golist
  File: usr.ppc64le/libexec/go-rpm-macros/golist

  Dynamic section at offset 0x3cfb78 contains 29 entries:
    Tag        Type                         Name/Value
   0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
   [...]
   0x0000000000000018 (BIND_NOW)           
   0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
   [...]

Whereas the x86_64 version of the same binary shows:

  % readelf -d usr.x86_64/libexec/go-rpm-macros/golist
  File: usr.x86_64/libexec/go-rpm-macros/golist

  Dynamic section at offset 0x3b5040 contains 12 entries:
    Tag        Type                         Name/Value
   0x0000000000000004 (HASH)               0x677de0
   [...]
   0x000000006ffffffb (FLAGS_1)            Flags: PIE
   [...]

So no NOW bit in the FLAGS_1 field and no BIND_NOW field.

However the final link command lines in the build logs appear to be the same:

  From the ppc64le build.log:

   go build -buildmode pie -compiler gc '-tags=rpm_crashtraceback ' -ldflags ' -B 0xbac2d7e5f21245b5f6ce832dacf49a6d1c2d7c32 -extldflags '\''-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '\''' -a -v -o /builddir/build/BUILD/golist-0.10.1/_build/bin/golist pagure.io/golist/cmd/golist

   From the x86_64 build log:

 go build -buildmode pie -compiler gc '-tags=rpm_crashtraceback ' -ldflags ' -B 0xf87b852735fda3e6ef437632790c629bf7cf94dd -extldflags '\''-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '\''' -a -v -o /builddir/build/BUILD/golist-0.10.1/_build/bin/golist pagure.io/golist/cmd/golist


I can only theorize that the x86_64 GO compiler is doing something different 
when constructing the actual command line that is passed to the linker.  Is
there a way to ask GO to explicitly display the linker command line ?

Comment 8 RHEL Program Management 2023-07-24 07:28:28 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


Note You need to log in before you can comment on or make changes to this bug.