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.

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.

These binaries are rust programs:

https://github.com/jthornber/thin-provisioning-tools/commit/61de3f92873310d8a25a8392f7e53ef67cc3d88c

and the versions match:

the tools were introduced in 0.9.0
https://gitlab.com/redhat/centos-stream/rpms/device-mapper-persistent-data/-/blob/c9s/device-mapper-persistent-data.spec#L215

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).

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?

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.

Thanks for chiming in, Joe. Can you confirm Nick's conclusion from comment 4 that those two binaries do not contain any code?

Let me get Marian (the packager) to double check for you.  There certainly should be code in there.

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.

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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days