Bug 2012797
| Summary: | annocheck reports that ld64.so.2 was not built with -D_FORTIFY_SOURCE=2 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Jan Pazdziora <jpazdziora> |
| Component: | annobin | Assignee: | Nick Clifton <nickc> |
| Status: | CLOSED ERRATA | QA Contact: | Václav Kadlčík <vkadlcik> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | ashankar, codonell, dj, fweimer, glibc-bugzilla, mcermak, mnewsome, nickc, pfrankli, sipoyare, skolosov, vkadlcik |
| Target Milestone: | rc | Keywords: | Bugfix, Triaged |
| Target Release: | --- | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | annobin-10.26-1.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-17 12:33:08 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: | |||
|
Description
Jan Pazdziora
2021-10-11 10:39:09 UTC
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 |