Description of problem: On ppc64le, annocheck no longer reports that /usr/lib64/ld64.so.2 would fail stack-prot test but it now reports failing fortify test, and potentially lto. Version-Release number of selected component (if applicable): glibc-2.34-7.el9.ppc64le annobin-annocheck-10.10-1.el9.ppc64le How reproducible: Deterministic. Steps to Reproduce: 1. annocheck --verbose /usr/lib64/ld64.so.2 Actual results: annocheck: Version 10.10. Hardened: /usr/lib64/ld64.so.2: PASS: pie test Hardened: /usr/lib64/ld64.so.2: info: set binary producer to GCC version 11. Hardened: /usr/lib64/ld64.so.2: PASS: optimization test Hardened: /usr/lib64/ld64.so.2: PASS: pic test Hardened: /usr/lib64/ld64.so.2: PASS: stack-prot test Hardened: /usr/lib64/ld64.so.2: info: ALSO written in Assembler (source: DW_AT_language string). Hardened: /usr/lib64/ld64.so.2: info: set binary producer to Gas version 2. Hardened: /usr/lib64/ld64.so.2: Command line options not recorded in DWARF DW_AT_producer variable. Hardened: /usr/lib64/ld64.so.2: PASS: writable-got test Hardened: /usr/lib64/ld64.so.2: PASS: dynamic-segment test Hardened: /usr/lib64/ld64.so.2: PASS: bind-now test Hardened: /usr/lib64/ld64.so.2: info: notes produced by gcc plugin version 1006 Hardened: /usr/lib64/ld64.so.2: skip: stack-prot test because function _dl_start_user is part of the C library's startup code, which executes before stack protection is established Hardened: /usr/lib64/ld64.so.2: FAIL: fortify test because -D_FORTIFY_SOURCE=2 was not present on the command line (function: _dl_start_user) Hardened: /usr/lib64/ld64.so.2: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-fortify.html Hardened: /usr/lib64/ld64.so.2: skip: glibcxx-assertions test because source language not C++ Hardened: /usr/lib64/ld64.so.2: PASS: warnings test Hardened: /usr/lib64/ld64.so.2: PASS: stack-clash test Hardened: /usr/lib64/ld64.so.2: info: notes produced by assembler plugin version 1 Hardened: /usr/lib64/ld64.so.2: skip: fortify test because not built by gcc/clang Hardened: /usr/lib64/ld64.so.2: PASS: gnu-stack test because stack segment exists with the correct permissions Hardened: /usr/lib64/ld64.so.2: PASS: gnu-relro test Hardened: /usr/lib64/ld64.so.2: PASS: notes test because no gaps found Hardened: /usr/lib64/ld64.so.2: skip: not-branch-protection test because not an AArch64 binary Hardened: /usr/lib64/ld64.so.2: skip: cf-protection test because not an x86 executable Hardened: /usr/lib64/ld64.so.2: skip: not-dynamic-tags test because AArch64 specific Hardened: /usr/lib64/ld64.so.2: PASS: entry test Hardened: /usr/lib64/ld64.so.2: skip: go-revision test because no GO compiled code found Hardened: /usr/lib64/ld64.so.2: MAYB: test: lto because no indication that LTO was used Hardened: /usr/lib64/ld64.so.2: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-lto.html Hardened: /usr/lib64/ld64.so.2: skip: only-go test because not compiled for x86 Hardened: /usr/lib64/ld64.so.2: PASS: production test Hardened: /usr/lib64/ld64.so.2: skip: property-note test because property notes not used Hardened: /usr/lib64/ld64.so.2: PASS: run-path test Hardened: /usr/lib64/ld64.so.2: PASS: rwx-seg test Hardened: /usr/lib64/ld64.so.2: PASS: short-enums test Hardened: /usr/lib64/ld64.so.2: skip: stack-realign test because not an x86 executable Hardened: /usr/lib64/ld64.so.2: PASS: textrel test Hardened: /usr/lib64/ld64.so.2: PASS: threads test Hardened: ld64.so.2: Overall: FAIL. Expected results: No FAIL. Additional info: With glibc-2.34-7.el9_b.ppc64le, the output was annocheck: Version 10.10. Hardened: /usr/lib64/ld64.so.2: PASS: pie test Hardened: /usr/lib64/ld64.so.2: info: set binary producer to GCC version 11. Hardened: /usr/lib64/ld64.so.2: PASS: optimization test Hardened: /usr/lib64/ld64.so.2: PASS: pic test Hardened: /usr/lib64/ld64.so.2: PASS: stack-prot test Hardened: /usr/lib64/ld64.so.2: info: ALSO written in Assembler (source: DW_AT_language string). Hardened: /usr/lib64/ld64.so.2: info: set binary producer to Gas version 2. Hardened: /usr/lib64/ld64.so.2: Command line options not recorded in DWARF DW_AT_producer variable. Hardened: /usr/lib64/ld64.so.2: PASS: writable-got test Hardened: /usr/lib64/ld64.so.2: PASS: dynamic-segment test Hardened: /usr/lib64/ld64.so.2: PASS: bind-now test Hardened: /usr/lib64/ld64.so.2: info: set binary producer to Gimple version 9. Hardened: /usr/lib64/ld64.so.2: info: notes produced by lto plugin version 9.90 Hardened: /usr/lib64/ld64.so.2: skip: fortify test because LTO compilation discards preprocessor options Hardened: /usr/lib64/ld64.so.2: skip: glibcxx-assertions test because source language not C++ Hardened: /usr/lib64/ld64.so.2: PASS: warnings test Hardened: /usr/lib64/ld64.so.2: PASS: lto test because LTO compilation detected Hardened: /usr/lib64/ld64.so.2: PASS: stack-clash test Hardened: /usr/lib64/ld64.so.2: info: notes produced by assembler plugin version 1 Hardened: /usr/lib64/ld64.so.2: FAIL: stack-prot test because stack protection deliberately disabled (function: dlmopen_doit) Hardened: /usr/lib64/ld64.so.2: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-stack-prot.html Hardened: /usr/lib64/ld64.so.2: FAIL: stack-prot test because stack protection deliberately disabled (function: is_trusted_path_normalize) Hardened: /usr/lib64/ld64.so.2: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-stack-prot.html Hardened: /usr/lib64/ld64.so.2: PASS: gnu-stack test because stack segment exists with the correct permissions Hardened: /usr/lib64/ld64.so.2: PASS: gnu-relro test Hardened: /usr/lib64/ld64.so.2: PASS: notes test because no gaps found Hardened: /usr/lib64/ld64.so.2: skip: not-branch-protection test because not an AArch64 binary Hardened: /usr/lib64/ld64.so.2: skip: cf-protection test because not an x86 executable Hardened: /usr/lib64/ld64.so.2: skip: not-dynamic-tags test because AArch64 specific Hardened: /usr/lib64/ld64.so.2: PASS: entry test Hardened: /usr/lib64/ld64.so.2: skip: go-revision test because no GO compiled code found Hardened: /usr/lib64/ld64.so.2: skip: only-go test because not compiled for x86 Hardened: /usr/lib64/ld64.so.2: PASS: production test Hardened: /usr/lib64/ld64.so.2: skip: property-note test because property notes not used Hardened: /usr/lib64/ld64.so.2: PASS: run-path test Hardened: /usr/lib64/ld64.so.2: PASS: rwx-seg test Hardened: /usr/lib64/ld64.so.2: PASS: short-enums test Hardened: /usr/lib64/ld64.so.2: skip: stack-realign test because not an x86 executable Hardened: /usr/lib64/ld64.so.2: PASS: textrel test Hardened: /usr/lib64/ld64.so.2: PASS: threads test Hardened: ld64.so.2: Overall: FAIL.
The fortify test failure: Hardened: /usr/lib64/ld64.so.2: FAIL: fortify test because -D_FORTIFY_SOURCE=2 was not present on the command line (function: _dl_start_user) is happening because the _dl_start_user() function is not in annocheck's list of known exceptions to the test. This will be fixed in the next release of annobin (10.15). The lto test failure however: Hardened: /usr/lib64/ld64.so.2: MAYB: test: lto because no indication that LTO was used Appears to be correct. It looks like the code was compiled with "-fno-lto". Is this expected ? IE does annocheck need to have a list of files which are expected to be compiled with LTO support ? (On RHEL-9 that is). Also - do the test results for the glibc-2.34-7.el9_b.ppc64le build need to be reviewed ? I am currently assuming that this is a side branch build and so not critical...
Doh. Typo. I meant: "IE does annocheck need to have a list of files which are expected to be compiled with*out* LTO support ?"
(In reply to Nick Clifton from comment #2) > The fortify test failure: > > Hardened: /usr/lib64/ld64.so.2: FAIL: fortify test because > -D_FORTIFY_SOURCE=2 was not present on the command line (function: > _dl_start_user) > > is happening because the _dl_start_user() function is not in annocheck's > list of known exceptions to the test. This will be fixed in the next > release of annobin (10.15). Correct, this is directly in the bootstrap sequence of the dynamic loader, and we cannot fortify it yet (the functions required for fortification are not yet reocated). (In reply to Nick Clifton from comment #3) > Doh. Typo. I meant: > > "IE does annocheck need to have a list of files which are expected to be > compiled with*out* LTO support ?" That's up to Platform Tools to decide. There will be packages that cannot use LTO, and we may wish to supress the LTO warnings for this. Marek was looking at the packages that could not be built with LTO. What does "MAYB: test: lto because no indication that LTO was used" actually mean? The dynamic loader uses a *very* specific *hand-crafted* link in order to meet the requirements of the bootstrap process, and for that we may never be able to use default flags, including LTO, which might migrate code into the bootstrap that needs relocations.
(In reply to Carlos O'Donell from comment #4) >> "IE does annocheck need to have a list of files which are expected to be >> compiled with*out* LTO support ?" > > That's up to Platform Tools to decide. There will be packages that cannot > use LTO, and we may wish to supress the LTO warnings for this. Marek was > looking at the packages that could not be built with LTO. Fair enough. My concern is to whether it is acceptable for these packages to waive the LTO test (or suppress it in their gating.yaml file), or if it is going to be necessary for annocheck to contain a list of known exceptions. > What does "MAYB: test: lto because no indication that LTO was used" actually > mean? It means that annocheck could not find any indication that the LTO was either explicitly enabled or disabled. Plus it also means that the binary was compiled at least partially either by GCC, G++, Clang or LLVM and hence could be expected to support an LTO option. Annocheck examines the notes produced by the annobin plugin, plus any options recorded in the DW_AT_producer string in the DWARF debug information (if it is present), for indications of LTO enablement.
I will add some special case exceptions for glibc excutables to annocheck.
Should this bug be moved to annobin? Based on earier comments ISTM both solutions (passthrough for glibc for _FORTIFY_SOURCE as well as lto) would need changes to annobin.
Fixed in annobin-10.26-1.el9
pre-verified: annobin-10.26-1.el9
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: annobin), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:2342