Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 646758

Summary: Add Spectre v2 (CVE-2017-5715) mitigation flags to the hardened gcc specs
Product: Gentoo Linux Reporter: Kerin Millar <kfm>
Component: HardenedAssignee: The Gentoo Linux Hardened Team <hardened>
Status: CONFIRMED ---    
Severity: normal CC: 89q1r14hd, alexander, gentoo, guillaume, jaak, sam, tsmksubc, viklevin2
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=727608
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 646076    
Bug Blocks: 643342, 750917    

Description Kerin Millar 2018-02-06 12:23:02 UTC
The release of gcc-7.3.0 supports the following flags which, as I understand it, would provide maximal generic protection against CVE-2017-5715 in userspace.

-mfunction-return=thunk -mindirect-branch=thunk -mindirect-branch-register

It would be nice for these to make it into the hardened gcc specs.

In addition, I think that the toolchain team should be persuaded to whitelist these flags in flag-o-matic.eclass. I have monkey-patched the eclass to this end, and have not experienced any issues in utilising the above CFLAGS across the entirety of my userspace.
Comment 1 Kerin Millar 2018-02-06 13:41:52 UTC
Bug 646076 exists for the issue of these flags being filtered out.
Comment 2 Kerin Millar 2022-06-10 11:08:59 UTC
At this point, I would retract the request for the specific flags that I mentioned in the opening comment. Thanks to Sam, they are no longer filtered by flag-o-matic but to incorporate them in the gcc specs might be a step too far as the performance loss can be severe.

I do wonder, though, whether it would make sense to get more users on -fcf-protection by default. At present, the current implementation only benefits Intel             processors that support Intel CET. Still, it doesn't appear to have any adverse effect on processors that do not; there are distributions that incorporate it as standard and they run perfectly well. One I'm aware of is Arch, which uses the following flags.

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection"

As an aside, I think -fno-plt makes sense now that PIE is ubiquitous?
Comment 3 Niklāvs Koļesņikovs 2022-06-10 12:40:55 UTC
Short summary: with GCC there's no way that I'm aware of that you can have both CET and Spectre mitigations enabled via make.conf for the whole system. Clang 14 seems to permit combining -mretpoline with -fcf-protection=full but I do not know if it's silently disabling something or if it genuinely works.

-fcf-protection would be NOP for most users, so, while the overhead should be low enough to use it by default, it won't actually offer any protection. I'll also note that man gcc does not specify what the default value or action of -fcf-protection is and that Fedora is, if I remember correctly, using -fcf-protectionf=full.

Unless I'm badly mistaken, only -mindirect-branch=thunk-extern is compatible with -fcf-protection=branch (and therefore full, too).  As far as I can tell/guess thunk-extern is something only upstreams can implement in their build system correctly, because, I think, it changes translation units as compiler sees them, and may result in confusing build failures.

Similarly -mindirect-branch-register is, I think, either for supporting free standing binaries or a performance optimization that was meant for [kernel?] upstream use and probably should not be set in make.conf.

Finally -mfunction-return, unless I'm confusing it with some other option, was implemented at kernel developers request in case if it's needed for mitigations of the worst case speculation that may or may not occur. I'm not aware of it ever having been deployed (but I could be wrong and it's actually used by something/someone).
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-06-10 12:44:57 UTC

(In reply to Kerin Millar from comment #2)
> At this point, I would retract the request for the specific flags that I
> mentioned in the opening comment. Thanks to Sam, they are no longer filtered
> by flag-o-matic but to incorporate them in the gcc specs might be a step too
> far as the performance loss can be severe.
> 

No problem. For things like this, feel free to ping me if needed.

> I do wonder, though, whether it would make sense to get more users on
> -fcf-protection by default. At present, the current implementation only
> benefits Intel             processors that support Intel CET. Still, it
> doesn't appear to have any adverse effect on processors that do not; there
> are distributions that incorporate it as standard and they run perfectly
> well. One I'm aware of is Arch, which uses the following flags.
> 

I've started work on this in bug 847148.

> CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
> -fstack-clash-protection -fcf-protection"
> 

I hope I can count on you to help me with F_S=3 testing? :)

(... and -D_GLIBCXX_ASSERTIONS)

> As an aside, I think -fno-plt makes sense now that PIE is ubiquitous?

Open to it, but not sure yet.

(In reply to Niklāvs Koļesņikovs from comment #3)
> Short summary: with GCC there's no way that I'm aware of that you can have
> both CET and Spectre mitigations enabled via make.conf for the whole system.
> Clang 14 seems to permit combining -mretpoline with -fcf-protection=full but
> I do not know if it's silently disabling something or if it genuinely works.
> 
> -fcf-protection would be NOP for most users, so, while the overhead should
> be low enough to use it by default, it won't actually offer any protection.
> I'll also note that man gcc does not specify what the default value or
> action of -fcf-protection is and that Fedora is, if I remember correctly,
> using -fcf-protectionf=full.

Know you're replying to Kerin, but let's keep CET talk in bug 847148 to make it easier to follow (although I know the first paragraph is somewhat about their combination, I'not aware of an incompatibility there).
Comment 5 Niklāvs Koļesņikovs 2022-06-10 13:04:26 UTC
What I tried to say is that this bug might be running out of time with both Spectre v2 mitigated and CET capable CPUs only becoming more prevalent, while concurrently at least GCC does not appear to have a way to mix the two hardening approaches for the entire system rather than at package level. Effectively limiting the domain where resolving this bug might help from both hardware and software sides.

In a sense there's now two or three sets of hardware:
1) too old for CET and vulnerable: -mindirect-branch=thunk in make.conf and hope for the best (but don't run any VM you do not fully trust)
1b) too old for CET but fully mitigated: -mindirect-branch=thunk and run VMs if you trust the protections and can accept the performance penalty
3) CET capable: -fcf-protection=full in make.conf is the obvious way to go

In an ideal world it would be okay or at least possible to just have one default for all but in this case the flags are literally incompatible (not to mention that people might not want to run -mindirect-branch on hardware which should already be sufficiently protected).
Comment 6 Kerin Millar 2022-06-10 16:04:18 UTC
(In reply to Sam James from comment #4)
> I hope I can count on you to help me with F_S=3 testing? :)
> 
> (... and -D_GLIBCXX_ASSERTIONS)

Certainly. I've been using -D_GLIBCXX_ASSERTIONS for some time, as it happens.

(In reply to Niklāvs Koļesņikovs from comment #3)
> -fcf-protection would be NOP for most users, so, while the overhead should
> be low enough to use it by default, it won't actually offer any protection.
> I'll also note that man gcc does not specify what the default value or
> action of -fcf-protection is and that Fedora is, if I remember correctly,
> using -fcf-protectionf=full.

Yes, that is aggravating. As with clang, -fcf-protection, alone, amounts to -fcf-protection=full.
Comment 7 Kerin Millar 2022-06-10 16:26:34 UTC
(In reply to Niklāvs Koļesņikovs from comment #5)
> In an ideal world it would be okay or at least possible to just have one
> default for all but in this case the flags are literally incompatible (not
> to mention that people might not want to run -mindirect-branch on hardware
> which should already be sufficiently protected).

Yes, indeed. That's another reason for retracting the proposal. I don't know why I didn't mention it earlier today.