On Wed, May 15, 2019 at 6:01 AM Adam Carter <adamcart...@gmail.com> wrote: > >> Am I correct to think that "Mitigation" is good enough or does that mean it >> could be affected in some other way or is risky? > > I accept Mitigation as good enough.
I'm not sure what alternative there would be... :) Everything reported in this directory is a CPU hardware vulnerability. If it reports that a CPU is not affected, then the CPU hardware doesn't contain the vulnerability and there is no way to exploit it on any OS/application/hypervisor/whatever. If it reports that it is vulnerable, then exploits can be run right now and the Linux kernel won't be doing anything to stop them, or can only mount an incomplete defense. If a vulnerability is not listed at all it means that it either doesn't apply to the architecture, or the kernel doesn't know about it. In the latter case you may or may not be vulnerable - the kernel simply doesn't know about it so if the underlying hardware contains the vulnerability then there will be no protection against it. The last state that is reported is mitigation followed by some detail. This means that your underlying cpu hardware contains the vulnerability, but the Linux kernel is applying some software mitigation to prevent it from being exploited. Generally this means that you aren't vulnerable in practice as long as you're running this particular kernel. Sometimes there might be more than one mitigation approach available and some of them might incur more of a performance penalty than others. However, if the kernel reports mitigated then it is the opinion of the kernel devs that you are not vulnerable. You might not be getting the best performance out of your CPU, but exploit code will not work. There are some vulnerabilities that will be reported as vulnerable, but with some additional partial mitigation reported. The overall message will start with vulnerable in this case with some detail following, such as: "spectre_v2:Vulnerable: Minimal generic ASM retpoline" In these cases the kernel devs have started to fix a vulnerability, but in their judgment the problem isn't fully resolved. This might happen when a vulnerability is first discovered, or if a microcode update isn't available and there isn't a workaround yet. In the latter case a more expensive workaround might eventually be developed and used if the microcode update isn't installed as a fallback. In general the kernel team prioritizes security over performance. CPU hardware vulnerabilities will often cost you something in performance, but if you're running the latest kernel and it doesn't report any problems then there shouldn't be any actual exploits. I have heard of datacenter admins seriously contemplating turning off some of the mitigations because of their performance cost. If you're running customer-provided VMs that is obviously not a reasonable approach, but if you're doing HPC in a highly-controlled datacenter, then the local priv escalation attacks may not be as much of a concern as needing to go out and rapidly buy/install another 200 hosts and the infrastructure needed to run them if preserving job execution time is critical. -- Rich
