Bug 1798776
| Summary: | /lib64/libsystemd.so.0 and /usr/lib64/security/pam_systemd.so aren't CET enabled | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | H.J. Lu <hongjiu.lu> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aoliva, avi.kivity, dmalcolm, fweimer, jakub, jwakely, law, lnykryn, mpolacek, msebor, msekleta, nickc, ssahani, s, systemd-maint, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-245.2-1.fc33 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-18 21:14:54 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: | |||
| Bug Depends On: | 1808484 | ||
| Bug Blocks: | 1802674 | ||
|
Description
H.J. Lu
2020-02-05 23:51:08 UTC
Hmm, what is CET and why should it be enabled? Intel Control-flow Enforcement Technology (CET): https://software.intel.com/en-us/articles/intel-sdm contains shadow stack (SHSTK) and indirect branch tracking (IBT). When CET is enabled, ELF object files must be marked with .note.gnu.property section. Also when IBT is enabled, all indirect branch targets must start with ENDBR instruction. OK, so that is the "what" part of the question. And why should it be enabled? Enable CET is one of Fedora's goals. Is this documented somewhere? (In reply to Zbigniew Jędrzejewski-Szmek from comment #5) > Is this documented somewhere? I found: https://bugzilla.redhat.com/show_bug.cgi?id=1538725 If you tell me what to change, I can do it. But right now this seems strictly undocumented, and I have no idea what to do where. AFAIK, systemd is compiled with the standard options mandated by the packaging guidelines. If something needs to be different, shouldn't the "global" definitions that apply across the distro be changed? (In reply to Zbigniew Jędrzejewski-Szmek from comment #7) > If you tell me what to change, I can do it. But right now this seems > strictly undocumented, and > I have no idea what to do where. > > AFAIK, systemd is compiled with the standard options mandated by the > packaging guidelines. > If something needs to be different, shouldn't the "global" definitions that > apply across the > distro be changed? All packages should be compiled with $optflags from rpmrc, which includes -fcf-protection. -fcf-protection will enable CET if sources are in C and C++. If there are assembly codes. CET needs to be enabled manually, like http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=4c88c2bd2a418435506325cd53246acaaa52750c http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=24b4d5c10a97aaf82ac7402cc3a5b429d580cd66 http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=22e577071790834f07753c42a191a568c9f2644d http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=cb9f0a2df8225eed071ae0a56265e38e9f6ff184 This seems to be caused by -flto. As you can see in the koji build [1], the appropriate flags
are all passed. When I compile locally (on F31) without -flto, I get the IBT flag. When I turn
on -flto using -Db_lto=true, the flag is gone.
$ meson configure build -Dc_args=-fcf-protection -Dc_link_args=-fcf-protection -Db_lto=false
$ ninja -C build pam_systemd.so -v && readelf -n build/pam_systemd.so 2>&1 | grep IBT
Properties: x86 feature: IBT, SHSTK
$ meson configure build -Dc_args=-fcf-protection -Dc_link_args=-fcf-protection -Db_lto=true
$ ninja -C build pam_systemd.so -v && readelf -n build/pam_systemd.so 2>&1 | grep IBT
(nothing)
gcc-9.2.1-1.fc31.x86_64
binutils-2.32-31.fc31.x86_64
OK, so let's move this one back to systemd, since #1808484 is assigned to gcc. Should be fixed now. |