Bug 1778557 - FAIL: GNU Property note is missing, but -fcf-protection is enabled.
Summary: FAIL: GNU Property note is missing, but -fcf-protection is enabled.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: opa-fm
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.2
Assignee: Honggang LI
QA Contact: zguo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-02 03:01 UTC by Honggang LI
Modified: 2020-04-28 16:57 UTC (History)
6 users (show)

Fixed In Version: opa-fm-10.10.0.0.444-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:56:52 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:1865 None None None 2020-04-28 16:57:23 UTC

Description Honggang LI 2019-12-02 03:01:17 UTC
Description of problem:

https://rpmdiff.engineering.redhat.com/run/423167/7/

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.

http://download.eng.bos.redhat.com/brewroot/vol/rhel-8/packages/opa-fm/10.10.0.0.444/1.el8/data/logs/x86_64/build.log

gcc -pie  -Wl,-z,noexecstack -z relro -z now      -L/builddir/build/BUILD/opa-fm-10.10.0.0.444/builtlibs.VIEO_HOST.release -Xlinker -rpath-link -Xlinker /builddir/build/BUILD/opa-fm-10.10.0.0.444/builtlibs.VIEO_HOST.release  -o build.VIEO_HOST.release/opafmvf build.VIEO_HOST.release/cmd_common.o build.VIEO_HOST.release/cmd_config.o build.VIEO_HOST.release/cmd_mgmt.o build.VIEO_HOST.release/cmd_query.o build.VIEO_HOST.release/opafmvf.o build.VIEO_HOST.release/tenant.o build.VIEO_HOST.release/utils.o -Xlinker --start-group -libverbs -libumad -lssl -lcrypto -lexpat -lpublic -lXml -lopamgt-priv  -Xlinker --end-group -lpthread


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


How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Nick Clifton 2019-12-02 14:09:00 UTC
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

Comment 2 Honggang LI 2019-12-03 03:54:56 UTC
(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.

Comment 7 errata-xmlrpc 2020-04-28 16:56:52 UTC
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


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