Hi Honggang LI,

> Detecting usr/lib/opa-fm/bin/opafmvf with not-hardened warnings '
> Hardened: opafmvf: FAIL: GNU Property note is missing, but -fcf-protection
> is enabled.' on x86_64

> I had checked all object files (*.o) and shared libraries for opafmvf. No
> file triggers this error message, but the final executable always failed the
> test.

This is correct.  The -fcf-protection option tells gcc to compile code with
support for hardware specific control-flow protections enabled.  This is a
security feature which helps prevents attackers from using the compiled code 
as part of their assault.  For Intel hardware this involves enabling the CET
feature of newer chips.  This can be done on a per-process basis, and it is
enabled by loader as a program starts.  

Enabling the feature however is an all-or-nothing event.  It will only work 
if all of the code in the program has been compiled to be CET aware.  Any 
code that has not been compiled will trigger a fault as soon as it is executed.
So the loader looks for a special flag in the executable that tells it that
every component in the program has been compiled to be CET aware.  If the flag
is missing, the feature is not enabled, and the executable is left vulnerable
to attacks.

The FAIL message from annocheck indicates that *some* parts of opafmvf have
been compiled to be CET aware, but others have not.  Thus the loader will
not enable CET.  This is probably a bad idea unless there is a good reason
for opafmvf to not use this feature.

There are no warnings when scanning object files or static libraries because 
they are never loaded directly.  They are always linked into programs which 
are then loaded.

Looking at the object files that are part of the opafmvf command line 
(eg cmd_common.o) it is obvious that they have not been compiled with
-fcf-protection enabled.  This must mean that opafmvf is being linked with 
one or more static libraries which do have -fcf-protection enabled.
(Annocheck will not produce its FAIL message if none of the components of 
the executable have been built with -fcf-protection enabled, and shared
libraries are checked separately).

I am not familiar with opafmvf or how it is built, so I am going to have
to hand over to you.  You need to decide if CET protection should be
enabled for opafmvf.  (It probably should).  If so, then you need to work
out how to get the option added to the compiler command lines.  (If
assembler sources are involved then things get tricky - give me a ping
if this is the case).   It should be noted that -fcf-protection is
already part of the default command line options when building with
rpm (via the rpm macros), so presumably opafmvf is being built with a
customised set of options.

If on the other hand, enabling CET is a no-no for opafmvf then you need
to locate the archives that are involved in the final link and which
have been built with -fcf-protection enabled.  (Shared libraries do not
matter, only static libraries).  If they are yours, then they need to
be built without -fcf-protection.  If they are system libraries then
you need to link against the shared versions instead.

Does this help ?

Cheers
  Nick

(In reply to Nick Clifton from comment #1)
> Does this help ?

Thanks for the explanation. I had confirmed opafmvf had been compiled with
hard-coded CFLAGS. Issue fixed after override hard-coded CFLAGS.

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, 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-2020:1865