Hi Jan,

  This appears to be happening because the affected binaries do not contain any
  annobin notes (apart from a single one from an assembler source file, probably
  crt1.S).  In addition the DWARF information in the separate debug info file 
  appears to be incomplete.  (It contains links to other debuginfo files which
  are not part of the debuginfo rpm).  So even if the debug information was being 
  provided to annocheck, it would not help it identify the tool that produced the
  binary.

  Basically the issue is that annocheck cannot determine how the binaries were
  built.  If they were not compiled from C/C++ then there is no need to check for
  the use of the -fstack-protector option.  Since the annobin notes are missing
  and there is no .comment section and no DWARF debug information available, 
  annocheck has to assume that the binary might not be compiled and hence it PASSes
  the test.

  Note - when I looked in the build.log for efivar I found that the libraries
  concerned appear to be built *three* times, once with annobin annotation enabled
  and then twice more without it.  I am not sure why this is done.

Cheers
  Nick

Thanks Nick. So do you reckon this is an issue in annobin, or a bug in the efivar build process? In other words, if we assume that those .so objects were built from a C/C++ code, should this be an annobin bugzilla, or an efivar bugzilla?

(In reply to Jan Pazdziora from comment #2)
> So do you reckon this is an issue in annobin, or a bug in the
> efivar build process? 

I think the efivar build process, but it may not be the process that is at fault, but one of the tools used by the process.  Eg if there is a bug in strip or gdb-add-index, then this might be causing the problems.

> In other words, if we assume that those .so objects
> were built from a C/C++ code, should this be an annobin bugzilla, or an
> efivar bugzilla?

Lets leave it with annobin for now, and I will investigate how efivar builds.  If I can show that it is another tool that is at fault then we can change the BZ.

Hmmm, this is interesting.  I checked out the efivar sources on the rhel-9.0.0 branch.  If I build the rpms locally, using "rhpkg local" then I end up with rpms which pass the stack-prot test, rather than skipping it.  If I build the same sources using brew ("rhpkg scratch-build") I end up with rpms which skip the stack-prot test, rather than passing it.

The difference is that the rpms which work still contain annobin notes (in the .gnu.build.attributes section) whereas the rpms which do not are devoid of annobin notes.#

Looking in the build logs for the two builds also shows an interesting difference.  The libefiboot library is built three times.  (The same is probably true for the other libraries in the efivar-libs rpm, but I did not check).  In the local build, all three compilations use the security hardening options and enable annobin notes.  In the brew scratch build only the first compilation does this.  The second two compilations run without security options and without annobin notes being created.

I am now looking into why this happens....

Right, so I have found a fix for the problem, but I do not know who is really to blame.

The issue is that the efivar.spec file builds the binaries three times, once in the %build stage using this command:

  make LIBDIR=%{_libdir} BINDIR=%{_bindir} CFLAGS="$RPM_OPT_FLAGS" LDFLAGS="$RPM_LD_FLAGS"

and then again in the %install stage using this command:

  %makeinstall

and then finally in the %check stage using this command:

  make abicheck

The %check build can be ignored - it does not get into the rpms - although it does increase the overall build time.  It is the %install build that is the issue.  This rebuilds all of the binaries, and without the security hardening options that are in RPM_OPT_FLAGS and RPM_LD_FLAGS.  

I found that if I changed the %install step to:

  %makeinstall CFLAGS="$RPM_OPT_FLAGS" LDFLAGS="$RPM_LD_FLAGS"

The final rpms worked, contained annobin notes, were built with the proper security options and passed annocheck's stack-prot test.

The thing I do not know is whether %makeinstall is supposed to correctly set CFLAGS and LDFLAGS itself, or if this is a bug in efivar.spec file.  Does anyone know ?

Checking with

readelf -Ws /usr/lib64/libefiboot.so.1.38 | grep '__stack_chk_fail'
readelf -Ws /usr/lib64/libefivar.so.1.38 | grep '__stack_chk_fail'

does not find anything, meaning the function to be called when the stack protection detects a corrupted stack is not referenced. So it seems to suggest -fstack-protector-strong was indeed not used.

Let me move this bugzilla to the efivar component since the suspicion of missing compiler flags is real.

Reproduced with efivar 38-2.el9 

# rpm -ql efivar-libs | grep /usr/lib64/ | while read f ; do test -L $f || echo $f ; done | xargs -- annocheck --verbose --skip-all --test-stack-prot
annocheck: Version 11.04.
Hardened: using profile: none.
Hardened: /usr/lib64/libefiboot.so.1.38: skip: stack-prot test because no code present - therefore no stack protection needed 
Hardened: /usr/lib64/libefiboot.so.1.38: Overall: PASS.
Hardened: /usr/lib64/libefisec.so.1.38: PASS: stack-prot test because option found in DW_AT_producer string 
Hardened: /usr/lib64/libefisec.so.1.38: Overall: PASS.
Hardened: /usr/lib64/libefivar.so.1.38: skip: stack-prot test because no code present - therefore no stack protection needed 
Hardened: /usr/lib64/libefivar.so.1.38: Overall: PASS.

Verified with efivar 38-3.el9

# rpm -ql efivar-libs | grep /usr/lib64/ | while read f ; do test -L $f || echo $f ; done | xargs -- annocheck --verbose --skip-all --test-stack-prot
annocheck: Version 11.04.
Hardened: using profile: none.
Hardened: /usr/lib64/libefiboot.so.1.38: PASS: stack-prot test because option found in DW_AT_producer string 
Hardened: /usr/lib64/libefiboot.so.1.38: Overall: PASS.
Hardened: /usr/lib64/libefisec.so.1.38: PASS: stack-prot test because option found in DW_AT_producer string 
Hardened: /usr/lib64/libefisec.so.1.38: Overall: PASS.
Hardened: /usr/lib64/libefivar.so.1.38: PASS: stack-prot test because option found in DW_AT_producer string 
Hardened: /usr/lib64/libefivar.so.1.38: Overall: PASS.

# rpm -qa efivar\* annobin-annocheck\*
annobin-annocheck-11.04-1.el9.x86_64
efivar-libs-38-3.el9.x86_64
efivar-debugsource-38-3.el9.x86_64
efivar-debuginfo-38-3.el9.x86_64
efivar-libs-debuginfo-38-3.el9.x86_64

efivar-38-3.el9 is in nightly RHEL-9.2.0-20230123.13
and works as in comment#11

Moving to VERIFIED

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 (efivar bug fix and enhancement update), 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/RHBA-2023:2565