Bug 2151899

Summary: annocheck reports that no compiled code found for thin_metadata_pack and thin_metadata_unpack binaries
Product: Red Hat Enterprise Linux 9 Reporter: Gabriel Gaspar Becker <ggasparb>
Component: device-mapper-persistent-dataAssignee: Marian Csontos <mcsontos>
Status: CLOSED MIGRATED QA Contact: Filip Suba <fsuba>
Severity: unspecified Docs Contact:
Priority: low    
Version: 9.0CC: agk, cwei, heinzm, jbrassow, jpazdziora, lvm-team, mcsontos, msnitzer, nickc, thornber
Target Milestone: rcKeywords: MigratedToJIRA, Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-09-23 18:48:29 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 Gabriel Gaspar Becker 2022-12-08 14:09:29 UTC
Description of problem:

Attempting to test if thin_metadata_pack|thin_metadata_unpack binaries were properly built with stack protection via -fstack-protector-strong yields skip: stack-prot test because no compiled code found.

Version-Release number of selected component (if applicable):

RHEL-9.0 packages:
device-mapper-persistent-data-0.9.0-12.el9.x86_64
annobin-annocheck-10.54-2.el9.x86_64

RHEL-9.2 packages:
device-mapper-persistent-data-0.9.0-13.el9.x86_64
annobin-annocheck-10.73-3.el9.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. dnf install -y annobin-annocheck device-mapper-persistent-data
2. dnf debuginfo-install -y device-mapper-persistent-data
3. rpm -ql device-mapper-persistent-data | grep /usr/sbin/ | while read f ; do test -L $f || echo $f ; done | xargs -- annocheck --verbose --skip-all --test-stack-prot

Actual results:

RHEL-9.0
annocheck: Version 10.54.
Hardened: /usr/sbin/pdata_tools: PASS: stack-prot test 
Hardened: /usr/sbin/pdata_tools: Overall: PASS.
Hardened: /usr/sbin/thin_metadata_pack: info: assembler built by GCC detected - treating as pure assembler.
Hardened: /usr/sbin/thin_metadata_pack: skip: stack-prot test because no compiled code found 
Hardened: /usr/sbin/thin_metadata_pack: Overall: PASS.
Hardened: /usr/sbin/thin_metadata_unpack: info: assembler built by GCC detected - treating as pure assembler.
Hardened: /usr/sbin/thin_metadata_unpack: skip: stack-prot test because no compiled code found 
Hardened: /usr/sbin/thin_metadata_unpack: Overall: PASS.


RHEL-9.2
annocheck: Version 10.73.
Hardened: /usr/sbin/pdata_tools: PASS: stack-prot test 
Hardened: /usr/sbin/pdata_tools: Overall: PASS.
Hardened: /usr/sbin/thin_metadata_pack: info: assembler built by GCC detected - treating as pure assembler.
Hardened: /usr/sbin/thin_metadata_pack: PASS: stack-prot test 
Hardened: /usr/sbin/thin_metadata_pack: Overall: PASS.
Hardened: /usr/sbin/thin_metadata_unpack: info: assembler built by GCC detected - treating as pure assembler.
Hardened: /usr/sbin/thin_metadata_unpack: skip: stack-prot test because no compiled code found 
Hardened: /usr/sbin/thin_metadata_unpack: Overall: PASS.

Expected results:
No "skip: stack-prot test because no compiled code found" on binaries.

Additional info:

Adding Nick to Cc in case this turns out to be an issue in annocheck itself.

Comment 1 Nick Clifton 2022-12-08 17:14:57 UTC
This is not really an error.  Annocheck has deduced that the thin_metadata_unpack binary does not contain any compiled code, and therefore does not need protection from stack clash attacks.

The newest version of annocheck (10.94) produces slightly different text, but overall the result is the same:

  annocheck: Version 10.94.
  [...]
  Hardened: ./usr/sbin/thin_metadata_unpack: info: assembler built by GCC detected - treating as pure assembler.
  Hardened: ./usr/sbin/thin_metadata_unpack: skip: stack-prot test because no code present - therefore no stack protection needed 
  Hardened: ./usr/sbin/thin_metadata_unpack: Overall: PASS.

Comment 2 Jan Pazdziora (Red Hat) 2022-12-08 20:19:27 UTC
Hello maintainers, does

# file /usr/sbin/thin_metadata_pack
/usr/sbin/thin_metadata_pack: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ff9f19e5bf68dadf34b05b439818f7d670287bcf, for GNU/Linux 3.2.0, stripped

contain some compiled code or not? I checked build.log but I couldn't find an explicit line where that binary is built / linked.

Comment 4 Nick Clifton 2022-12-09 16:00:59 UTC
Just to be clear, whilst the device-mapper-persistent-data package may contain code written in Rust, the two binaries which are producing problematic annocheck results - thin_metadata_pack and thin_metadata_unpack - do not contain any code.  (At least none that I can find).

Comment 5 Jan Pazdziora (Red Hat) 2023-02-06 14:12:36 UTC
For the record, annocheck 11.05 reports

  skip: stack-prot test because sources compiled as if they were assembler are not checked by this test
  skip: pic test because sources compiled as if they were assembler are not checked

Hello LVM / device-mapper maintainers, is this assessment of these two binaries by annocheck correct?

Comment 6 Joe Thornber 2023-02-06 16:26:38 UTC
Those two tools in v0.9 are written in Rust.  I don't know why your annocheck tool objects to them.

The latest v1.0 version of thinp tools contains only Rust tools, so you may get more of these messages.

Comment 7 Jan Pazdziora (Red Hat) 2023-02-06 16:31:37 UTC
Thanks for chiming in, Joe. Can you confirm Nick's conclusion from comment 4 that those two binaries do not contain any code?

Comment 8 Joe Thornber 2023-02-06 16:34:05 UTC
Let me get Marian (the packager) to double check for you.  There certainly should be code in there.

Comment 9 RHEL Program Management 2023-09-23 18:36:30 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 10 RHEL Program Management 2023-09-23 18:48:29 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

Comment 11 Red Hat Bugzilla 2024-01-22 04:25:25 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days