| Summary: | Add Spectre v2 (CVE-2017-5715) mitigation flags to the hardened gcc specs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | kfm |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | 89q1r14hd, alexander, arthur, 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
kfm
2018-02-06 12:23:02 UTC
Bug 646076 exists for the issue of these flags being filtered out. 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? 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). (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). 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). (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. (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. |
