Bug 1997759
| Summary: | annocheck gating output complains about 'CET' and mixing Go and non-Go object files | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Brian Lane <bcl> |
| Component: | annobin | Assignee: | Nick Clifton <nickc> |
| Status: | CLOSED ERRATA | QA Contact: | Václav Kadlčík <vkadlcik> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | dcantrell, fweimer, mcermak, nickc |
| Target Milestone: | rc | Keywords: | Bugfix, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | annobin-10.09-1.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-17 12:33:04 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
Brian Lane
2021-08-25 18:41:57 UTC
(In reply to Brian Lane from comment #0) Hi Brian, > Hardened: /usr/bin/composer-cli: FAIL: only-go test because combining GO and > non-GO object files on x86 systems is not safe - it disables CET > > Hardened: /usr/libexec/tests/composer-cli/composer-cli-tests: FAIL: > cf-protection test because CET enabling note missing Short answer: please feel free to waive these results. Long answer: > weldr-client isn't mixing object files, there is only Go code in the > project. Actually it does mix C and GO, because it is linking with code from the glibc library. (Including some thread functions by the look of it). > And I have no idea what CET is, CET is a new feature from Intel that is present in the very latest chips. It stands for "Control Flow Enforcement Technology" and the idea is that it stops certain kinds of attacks on compiled programs. (JOP and ROP attacks if that means anything to you). The problem with the feature is that it is an all or nothing type of thing. Either all of the code in a program must be compiled to support it or else it will not work. Currently the GO compiler does not support generating CET-aware code on x86/x86_64 machines, and hence annocheck is producing these FAIL messages. Since this is a known problem with the GO compiler, and nothing at all to do with your package's code, there is no need for you to be concerened and you can just waive the result. Ideally a future release of the GO compiler will fix this problem. > In a previous run, with annocheck 9.86, these failures didn't appear at all: Which is odd because the FAILs should have been there. > http://artifacts.osci.redhat.com/testing-farm/8e4ed956-7b91-4039-a7d6-ce566c3809e4/work-rpminspectmj034O/rpminspect/execute/data/annocheck/output.txt Looking at this output there are no tests of the x86_64 binaries, which is why you did not encounter any FAIL results. I have no idea why the x86_64 tests were omitted however. Given all of this, are you happy if I CLOSE this BZ ? Cheers Nick (In reply to Nick Clifton from comment #1) > (In reply to Brian Lane from comment #0) > Hi Brian, > > > Hardened: /usr/bin/composer-cli: FAIL: only-go test because combining GO and > > non-GO object files on x86 systems is not safe - it disables CET > > > > Hardened: /usr/libexec/tests/composer-cli/composer-cli-tests: FAIL: > > cf-protection test because CET enabling note missing > > Short answer: please feel free to waive these results. > > > Long answer: > > > weldr-client isn't mixing object files, there is only Go code in the > > project. > > Actually it does mix C and GO, because it is linking with code from the > glibc library. (Including some thread functions by the look of it). > > > > And I have no idea what CET is, > > CET is a new feature from Intel that is present in the very latest chips. > It stands for "Control Flow Enforcement Technology" and the idea is that > it stops certain kinds of attacks on compiled programs. (JOP and ROP > attacks if that means anything to you). > > The problem with the feature is that it is an all or nothing type of thing. > Either all of the code in a program must be compiled to support it or else > it will not work. Currently the GO compiler does not support generating > CET-aware code on x86/x86_64 machines, and hence annocheck is producing > these FAIL messages. > > Since this is a known problem with the GO compiler, and nothing at all > to do with your package's code, there is no need for you to be concerened > and you can just waive the result. Ideally a future release of the GO > compiler will fix this problem. Given that this is a known problem with the GO compiler, this is going to be an ongoing finding by annocheck that developers will be able to do nothing about. Can an option be passed to annocheck to at least crank this down from FAIL in the interim? Waiving as proper procedure is a bad workflow, so if this is to be ignored for now then we should invoke annocheck in a way that does not report this as FAIL for now. annocheck options used by rpminspect are defined in /usr/share/rpminspect/redhat.yaml in the rpminspect-data-redhat package which lives at https://gitlab.cee.redhat.com/osci/rpminspect-data-redhat > > In a previous run, with annocheck 9.86, these failures didn't appear at all: > > Which is odd because the FAILs should have been there. > > > http://artifacts.osci.redhat.com/testing-farm/8e4ed956-7b91-4039-a7d6-ce566c3809e4/work-rpminspectmj034O/rpminspect/execute/data/annocheck/output.txt > > Looking at this output there are no tests of the x86_64 binaries, which is > why > you did not encounter any FAIL results. I have no idea why the x86_64 tests > were omitted however. > > > Given all of this, are you happy if I CLOSE this BZ ? > > Cheers > Nick (In reply to David Cantrell from comment #2) > Can an option be passed to annocheck to at least crank this down > from FAIL in the interim? There already is such an option. Or rather two options, because two tests are failing: --skip-only-go and --skip-cf-protection. Using the latter would be a bad idea however as the cf-protection test is important for non-GO binaries. Plus these options would have to be added to the script used by rpminsect that invokes annocheck. A better solution, I would suggest, is to have annocheck SKIP these tests if it detects that it is examining a GO compiled binary. Then when the GO compiler is updated to add CET support, the tests can be reinstated. I have a local patch to annocheck that does this, but given the fact that changes to RHEL-9-beta now need exception+ status, I have pushed this BZ out to RHEL-9.0 instead. (In reply to Nick Clifton from comment #3) > (In reply to David Cantrell from comment #2) > > > > Can an option be passed to annocheck to at least crank this down > > from FAIL in the interim? > > There already is such an option. Or rather two options, because two tests > are failing: --skip-only-go and --skip-cf-protection. Using the latter > would be a bad idea however as the cf-protection test is important for non-GO > binaries. Plus these options would have to be added to the script used by > rpminsect that invokes annocheck. rpminspect doesn't run a script to run annocheck. It just uses popen() with a command line built starting with the options defined in the config file. In rpminspect-data-redhat (https://gitlab.cee.redhat.com/osci/rpminspect-data-redhat) the main program configuration file is redhat.yaml. In the annocheck section, you can define any number of annocheck "runs" you want rpminspect to perform. A run has an arbitrary name, a colon, then the command line options that should be used with annocheck. By default there is one run defined and in rpminspect-data-redhat it's called "rhel-policy". In rpminspect-data-fedora, we spell it "hardened". https://gitlab.cee.redhat.com/osci/rpminspect-data-redhat/-/blob/master/redhat.yaml#L478 Changing these options does not require modification to rpminspect, so we can restructure the product config files as we see fit. Also, the config file for rpminspect is YAML, which I apologize for. A down the road item is to migrate away from YAML because it's just too frustrating to deal with. Since it's YAML syntax, the format for the entries in the annocheck section is: HYPHEN WHITESPACE NAME COLON WHITESPACE OPTIONS > A better solution, I would suggest, is to have annocheck SKIP these tests > if it detects that it is examining a GO compiled binary. Then when the GO > compiler is updated to add CET support, the tests can be reinstated. I > have a local patch to annocheck that does this, but given the fact that > changes to RHEL-9-beta now need exception+ status, I have pushed this BZ > out to RHEL-9.0 instead. That's reasonable, though it would be nice to have a solution for the time between 9 beta and GA. Fixed in annobin-10.06-1.el9 Right, please try: annobin-10.09-1.el9 verified: annobin-10.10-1.el9 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 (new packages: annobin), 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-2022:2342 |