RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1978176 - annobin: Needs rebuild for gcc-11.1.1-6.1.el9 to fix buildroot
Summary: annobin: Needs rebuild for gcc-11.1.1-6.1.el9 to fix buildroot
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: annobin
Version: 9.0
Hardware: All
OS: Linux
urgent
high
Target Milestone: beta
: ---
Assignee: Nick Clifton
QA Contact: Martin Cermak
URL:
Whiteboard:
: 1977997 1979523 1980480 (view as bug list)
Depends On:
Blocks: 1958224
TreeView+ depends on / blocked
 
Reported: 2021-07-01 09:06 UTC by Florian Weimer
Modified: 2021-12-07 21:23 UTC (History)
8 users (show)

Fixed In Version: annobin-9.79-1.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-12-07 21:20:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Florian Weimer 2021-07-01 09:06:22 UTC 
A recent glibc-2.33.9000-36.el9 build ran into a buildroot inconsistency:

annocheck: Version 9.72.
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: pie test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: property-note test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: writeable-got test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: dynamic-segment test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: bind-now test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: look: PAC_PLT tag is missing from dynamic tags.
Hardened: /usr/lib64/gconv/ARMSCII-8.so: ^^^^:  This test is not yet enabled, but if it was enabled, it would fail...
Hardened: /usr/lib64/gconv/ARMSCII-8.so: info: set binary producer to Gas version 2.
Hardened: /usr/lib64/gconv/ARMSCII-8.so: info: notes produced by assembler plugin version 1
Hardened: /usr/lib64/gconv/ARMSCII-8.so: info: set binary producer to Gimple version 9.
Hardened: /usr/lib64/gconv/ARMSCII-8.so: info: notes produced by lto plugin version 9.76
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: stack-prot test 
Hardened: Hardened: /usr/lib64/gconv/ARMSCII-8.so: The annobin plugin was built by an older version of the compiler.
Hardened: debug: Annobin plugin was built by gcc 11.0.1 but run on gcc version 11.1.1.
Hardened: debug: If there are WARN or FAIL results that appear to be incorrect, it could be due to this discrepancy.
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: pic test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: skip: fortify test because LTO compilation discards preprocessor options 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: glibcxx-assertions test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: optimization test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: skip: warnings test because LTO compilation discards preprocessor options 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: lto test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: MAYB: test: branch-protection because unexpected note value (function: component: gconv_init) 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: FAIL: stack-clash test because -fstack-clash-protection not enabled (function: gconv_init) 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: gnu-stack test because stack segment exists with the correct permissions 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: gnu-relro test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: notes test because no gaps found 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: skip: cf-protection test because not an x86 executable 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: look: no dynamic tags found.
Hardened: /usr/lib64/gconv/ARMSCII-8.so: ^^^^:  This test is not yet enabled, but if it was enabled, it would fail...
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: entry test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: skip: go-revision test because no GO compiled code found 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: skip: only-go test because not compiled for x86 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: production test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: run-path test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: rwx-seg test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: short-enum test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: skip: stack-realign test because not an x86 executable 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: textrel test 
Hardened: /usr/lib64/gconv/ARMSCII-8.so: PASS: threads test
Comment 2 Nick Clifton 2021-07-01 10:46:47 UTC 
Fixed in annobin-9.79-1.el9
Comment 3 Kamil Dudka 2021-07-01 14:31:20 UTC 
Do I need to rebuild coreutils-8.32-29.el9 which was built with a wrong combination of gcc/annobin?

    https://dashboard.osci.redhat.com/#/artifact/brew-build/aid/37838342?focus=id:e845dd5f7efbf640456dd93519793e437420339b80a1f7ebe831175786959880
Comment 4 Nick Clifton 2021-07-01 14:52:56 UTC 
(In reply to Kamil Dudka from comment #3)
Hi Kamil,

> Do I need to rebuild coreutils-8.32-29.el9 which was built with a wrong
> combination of gcc/annobin?

No.

The new version of annobin is still in gating at the moment, so until it makes it through to the buildroot the problem will persist.

Also - there is nothing actually wrong being detected.  Annocheck is saying that any "FAIL" results that appear to be bogus could be due to the discrepancy between the version of gcc used to build the annobin plugin and the version of gcc which ran the plugin.  But the log does not show any FAIL results.  So there is nothing to be concerned about.  (I am not sure why this is actually showing up as a failed test.  Perhaps the test harness is looking for the string "FAIL" rather than checking the return code from annocheck.  That would be rather ironic though).

So for now please just waive the coreutils gating failure.  Hopefully the next time you build the coreutils the buildroot will have been updated and this problem will be resolved[*].

Cheers
  Nick

[*] Except that exactly the same thing could happen again in the future.  Ie if gcc is updated and gets into the buildroot, but annobin is not updated, then annocheck will notice and start to complain again.  We try to keep the two in sync, but occasionally there are slip ups.
Comment 5 Kamil Dudka 2021-07-01 16:11:54 UTC 
(In reply to Nick Clifton from comment #4)
> The new version of annobin is still in gating at the moment, so until it
> makes it through to the buildroot the problem will persist.

No worries.  I would certainly wait for a fixed build of annobin to appear in the buildroot before resubmitting the build of coreutils.  My question was more whether it would be fine to release such a build of coreutils in el9 beta in the unlikely case that coreutils were not rebuilt from now on.

> Also - there is nothing actually wrong being detected.  Annocheck is saying
> that any "FAIL" results that appear to be bogus could be due to the
> discrepancy between the version of gcc used to build the annobin plugin and
> the version of gcc which ran the plugin.  But the log does not show any FAIL
> results.  So there is nothing to be concerned about.  (I am not sure why
> this is actually showing up as a failed test.  Perhaps the test harness is
> looking for the string "FAIL" rather than checking the return code from
> annocheck.  That would be rather ironic though).

Actually I can see a lot of FAIL results in various binaries on various architectures, for example:

Hardened: /usr/bin/arch: FAIL: stack-clash test because -fstack-clash-protection not enabled (addr range: 0x2420..0x6aa0) 
Hardened: /usr/bin/arch: FAIL: stack-clash test because -fstack-clash-protection not enabled (addr range: 0x2ae0..0x69dc)
[...]
Hardened: /usr/bin/csplit: FAIL: stack-realign test because -fstack-realign not enabled (function: quotearg_buffer_restyled.constprop.0.cold) 
[...]
Hardened: /usr/bin/cp: FAIL: cf-protection test because no protection enabled (function: triple_hash_no_name) 
Hardened: /usr/bin/cp: FAIL: stack-clash test because -fstack-clash-protection not enabled (function: triple_hash_no_name) 
Hardened: /usr/bin/cp: FAIL: cf-protection test because no protection enabled (function: isaac_refill) 
Hardened: /usr/bin/cp: FAIL: stack-clash test because -fstack-clash-protection not enabled (function: isaac_refill) 

None of them appeared in the annocheck output of coreutils-8.32-28.el9, which ran two weeks ago.
Comment 6 Nick Clifton 2021-07-05 10:04:28 UTC 
*** Bug 1978573 has been marked as a duplicate of this bug. ***
Comment 7 Nick Clifton 2021-07-05 10:06:22 UTC 
*** Bug 1977997 has been marked as a duplicate of this bug. ***
Comment 8 Nick Clifton 2021-07-05 10:13:17 UTC 
(In reply to Kamil Dudka from comment #5)

Hi Kamil,

> Actually I can see a lot of FAIL results in various binaries on various
> architectures, for example:
> 
> Hardened: /usr/bin/arch: FAIL: stack-clash test because
> -fstack-clash-protection not enabled (addr range: 0x2420..0x6aa0) 

Hmm, I must have missed these. Sorry.
OK, so the warning from annocheck is probably correct - these FAIL results are happening because an old version of annobin was used with a new version of gcc.  Hopefully the new build of annobin should fix this.

Cheers
  Nick
Comment 9 Nick Clifton 2021-07-06 12:45:48 UTC 
*** Bug 1979523 has been marked as a duplicate of this bug. ***
Comment 12 Nick Clifton 2021-07-09 13:21:59 UTC 
*** Bug 1980480 has been marked as a duplicate of this bug. ***
Comment 13 Jan Pazdziora 2021-07-12 14:12:45 UTC 
I've started to specifically test latest glibc builds. The gcc version discrepancy messages are gone but there are still FAILs reported: bug 1981410.
Note You need to log in before you can comment on or make changes to this bug.