1 |
On Wed, May 15, 2019 at 6:01 AM Adam Carter <adamcarter3@×××××.com> wrote: |
2 |
> |
3 |
>> 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? |
4 |
> |
5 |
> I accept Mitigation as good enough. |
6 |
|
7 |
I'm not sure what alternative there would be... :) |
8 |
|
9 |
Everything reported in this directory is a CPU hardware vulnerability. |
10 |
If it reports that a CPU is not affected, then the CPU hardware |
11 |
doesn't contain the vulnerability and there is no way to exploit it on |
12 |
any OS/application/hypervisor/whatever. If it reports that it is |
13 |
vulnerable, then exploits can be run right now and the Linux kernel |
14 |
won't be doing anything to stop them, or can only mount an incomplete |
15 |
defense. |
16 |
|
17 |
If a vulnerability is not listed at all it means that it either |
18 |
doesn't apply to the architecture, or the kernel doesn't know about |
19 |
it. In the latter case you may or may not be vulnerable - the kernel |
20 |
simply doesn't know about it so if the underlying hardware contains |
21 |
the vulnerability then there will be no protection against it. |
22 |
|
23 |
The last state that is reported is mitigation followed by some detail. |
24 |
This means that your underlying cpu hardware contains the |
25 |
vulnerability, but the Linux kernel is applying some software |
26 |
mitigation to prevent it from being exploited. Generally this means |
27 |
that you aren't vulnerable in practice as long as you're running this |
28 |
particular kernel. Sometimes there might be more than one mitigation |
29 |
approach available and some of them might incur more of a performance |
30 |
penalty than others. However, if the kernel reports mitigated then it |
31 |
is the opinion of the kernel devs that you are not vulnerable. You |
32 |
might not be getting the best performance out of your CPU, but exploit |
33 |
code will not work. |
34 |
|
35 |
There are some vulnerabilities that will be reported as vulnerable, |
36 |
but with some additional partial mitigation reported. The overall |
37 |
message will start with vulnerable in this case with some detail |
38 |
following, such as: |
39 |
"spectre_v2:Vulnerable: Minimal generic ASM retpoline" |
40 |
In these cases the kernel devs have started to fix a vulnerability, |
41 |
but in their judgment the problem isn't fully resolved. This might |
42 |
happen when a vulnerability is first discovered, or if a microcode |
43 |
update isn't available and there isn't a workaround yet. In the |
44 |
latter case a more expensive workaround might eventually be developed |
45 |
and used if the microcode update isn't installed as a fallback. |
46 |
|
47 |
In general the kernel team prioritizes security over performance. CPU |
48 |
hardware vulnerabilities will often cost you something in performance, |
49 |
but if you're running the latest kernel and it doesn't report any |
50 |
problems then there shouldn't be any actual exploits. |
51 |
|
52 |
I have heard of datacenter admins seriously contemplating turning off |
53 |
some of the mitigations because of their performance cost. If you're |
54 |
running customer-provided VMs that is obviously not a reasonable |
55 |
approach, but if you're doing HPC in a highly-controlled datacenter, |
56 |
then the local priv escalation attacks may not be as much of a concern |
57 |
as needing to go out and rapidly buy/install another 200 hosts and the |
58 |
infrastructure needed to run them if preserving job execution time is |
59 |
critical. |
60 |
|
61 |
-- |
62 |
Rich |