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 1904479 - annobin: Missing _FORTIFY_SOURCE macro results in MAYBE
Summary: annobin: Missing _FORTIFY_SOURCE macro results in MAYBE
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: annobin
Version: 8.4
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: rc
: 8.4
Assignee: Nick Clifton
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-04 15:25 UTC by Martin Cermak
Modified: 2021-09-17 14:30 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of: 1703500
Environment:
Last Closed: 2021-01-13 09:39:15 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Comment 1 Nick Clifton 2020-12-08 11:40:14 UTC
We need to rebase to 9.48 in order to fix this bug.

Comment 3 Nick Clifton 2020-12-09 15:04:51 UTC
OK. lets try annobin-9.49-1.el8...

Comment 13 Nick Clifton 2020-12-15 11:42:04 UTC
Fixed in annobin-9.52-1.el9

Comment 21 Nick Clifton 2021-01-12 10:52:22 UTC
Right - I do not think that it is possible to achieve the desired result with this test, if LTO compilation is enabled.  Essentially the LTO compiler is not told about preprocessor options like -D_FORTIFY_SOURCE, so the annobin plugin run during LTO compilation cannot know if it was defined or not.  The annobin plugin that is run before LTO compilation happens does know, but it has no way of communicating with the other plugin.  (I have tried lots of methods of solving this problem, none have worked).

In theory annocheck could examine the built binary to see if it invokes any of the functions that are affected by _FORTIFY_SOURCE, eg strcpy.  If the fortified version of the function is used then all is well, and if the unfortified version is used then there might be a problem.  But this will not work for the test case, since it does not use any of these functions.  Nor will it work for programs where the fortified functions cannot be used, even when -D_FORTIFY_SOURCE=2 is used.  (Fortification only works for certain categories of algorithm).

So instead I have implemented the following:

  * If LTO is not enabled, the annobin plugin records the notes correctly and annocheck will correctly generate PASS or FAIL results.
  * If LTO is enabled but -D_FORTIFY_SOURCE is not enabled then the pre-LTO annobin plugin will generate a warning message.
    (Prior to annobin 9.55 this was just a message on stdout.  From 9.55 onwards this is a real gcc warning message).
  * If LTO is enabled then the LTO plugin will generate a special note telling annocheck that the fortify level is unknown because of LTO.  In turn annocheck will SKIP this test, since it has no reliable way to determine the level, and in most cases the user will have done the right thing.

Can I suggest that in order for the test to work you change this line:

 gcc `rpm --eval "%build_cflags %build_ldflags" | sed s/-Wp,-D_FORTIFY_SOURCE=2//` u.c

to: 

  gcc `rpm --eval "%build_cflags %build_ldflags" | sed s/-Wp,-D_FORTIFY_SOURCE=2//` u.c -fno-lto

If this is satisfactory then I would like to set this BZ to CLOSE/WONTFIX.

Comment 22 Martin Cermak 2021-01-13 09:39:15 UTC
Nick, I've updated the testcase.  Thank you for looking into this.


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