Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
We don't treat the ori31 speculation barrier as a mitigation on its
own, because it has to be *used* by code in order to be a mitigation
and we don't know if userspace is doing that. So if that's all we see
we say:
Vulnerable, ori31 speculation barrier enabled
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit d6fbe1c55c55c6937cbea3531af7da84ab7473c3 linux-next)
Signed-off-by: Tyler Hicks <email address hidden>
Add a definition for cpu_show_spectre_v1() to override the generic
version. Currently this just prints "Not affected" or "Vulnerable"
based on the firmware flag.
Although the kernel does have array_index_nospec() in a few places, we
haven't yet audited all the powerpc code to see where it's necessary,
so for now we don't list that as a mitigation.
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 56986016cb8cd9050e601831fe89f332b4e3c46e linux-next)
Signed-off-by: Tyler Hicks <email address hidden>
Now that we have the security flags we can significantly simplify the
code in pnv_setup_rfi_flush(), because we can use the flags instead of
checking device tree properties and because the security flags have
pessimistic defaults.
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 37c0bdd00d3ae83369ab60a6712c28e11e6458d5 linux-next)
Signed-off-by: Tyler Hicks <email address hidden>
This landed in setup_64.c for no good reason other than we had nowhere
else to put it. Now that we have a security-related file, that is a
better place for it so move it.
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 8ad33041563a10b34988800c682ada14b2612533 linux-next)
Signed-off-by: Tyler Hicks <email address hidden>
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source for details.
Arguably these could be firmware features, but that then requires them
to be read early in boot so they're available prior to asm feature
patching, but we don't actually want to use them for patching. We may
also want to dynamically update them in future, which would be
incompatible with the way firmware features work (at the moment at
least). So for now just make them separate flags.
Signed-off-by: Michael Ellerman <email address hidden>
(cherry picked from commit 9a868f634349e62922c226834aa23e3d1329ae7f linux-next)
Signed-off-by: Tyler Hicks <email address hidden>
