Bug 1778557
Summary: | FAIL: GNU Property note is missing, but -fcf-protection is enabled. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Honggang LI <honli> |
Component: | opa-fm | Assignee: | Honggang LI <honli> |
Status: | CLOSED ERRATA | QA Contact: | zguo <zguo> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.2 | CC: | fweimer, hwkernel-mgr, mcermak, nickc, rdma-dev-team, zguo |
Target Milestone: | rc | ||
Target Release: | 8.2 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | opa-fm-10.10.0.0.444-2.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-04-28 16:56:52 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
Honggang LI
2019-12-02 03:01:17 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 (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 |