Bug 2044491

Summary: annocheck FAIL: bind-now test because not linked with -Wl,-z,now (golist on aarch64 and x86_64)
Product: Red Hat Enterprise Linux 9 Reporter: Edjunior Barbosa Machado <emachado>
Component: go-rpm-macrosAssignee: David Benoit <dbenoit>
Status: NEW --- QA Contact: Edjunior Barbosa Machado <emachado>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: asm, dbenoit, emachado, jdanek, nickc, tstellar
Target Milestone: rcKeywords: Bugfix, Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-24 07:28:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
annocheck output none

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.