| Message ID | 20190321230557.45107-1-jeremy.linton@arm.com |
|---|---|
| Headers | show |
| Series | arm64: add system vulnerability sysfs entries | expand |
On Thu, 21 Mar 2019 18:05:47 -0500 Jeremy Linton <jeremy.linton@arm.com> wrote: Hi, > Arm64 machines should be displaying a human readable > vulnerability status to speculative execution attacks in > /sys/devices/system/cpu/vulnerabilities > > This series enables that behavior by providing the expected > functions. Those functions expose the cpu errata and feature > states, as well as whether firmware is responding appropriately > to display the overall machine status. This means that in a > heterogeneous machine we will only claim the machine is mitigated > or safe if we are confident all booted cores are safe or > mitigated. > > v5->v6: > Invert meltdown logic to display that a core is safe rather > than mitigated if the mitigation has been enabled on > machines that are safe. This can happen when the > mitigation was forced on via command line or KASLR. > This means that in order to detect if kpti is enabled > other methods must be used (look at dmesg) when the > machine isn't itself susceptible to meltdown. > Trivial whitespace tweaks. Thanks for those changes, I am happy with them. The whole series looks ready to me now. Cheers, Andre. > v4->v5: > Revert the changes to remove the CONFIG_EXPERT hidden > options, but leave the detection paths building > without #ifdef wrappers. Also remove the > CONFIG_GENERIC_CPU_VULNERABILITIES #ifdefs > as we are 'select'ing the option in the Kconfig. > This allows us to keep all three variations of > the CONFIG/enable/disable paths without a lot of > (CONFIG_X || CONFIG_Y) checks. > Various bits/pieces moved between the patches in an attempt > to keep similar features/changes together. > > v3->v4: > Drop the patch which selectivly exports sysfs entries > Remove the CONFIG_EXPERT hidden options which allowed > the kernel to be built without the vulnerability > detection code. > Pick Marc Z's patches which invert the white/black > lists for spectrev2 and clean up the firmware > detection logic. > Document the existing kpti controls > Add a nospectre_v2 option to boot time disable the > mitigation > > v2->v3: > Remove "Unknown" states, replace with further blacklists > and default vulnerable/not affected states. > Add the ability for an arch port to selectively export > sysfs vulnerabilities. > > v1->v2: > Add "Unknown" state to ABI/testing docs. > Minor tweaks. > > Jeremy Linton (6): > arm64: Provide a command line to disable spectre_v2 mitigation > arm64: add sysfs vulnerability show for meltdown > arm64: Always enable spectrev2 vulnerability detection > arm64: add sysfs vulnerability show for spectre v2 > arm64: Always enable ssb vulnerability detection > arm64: add sysfs vulnerability show for speculative store bypass > > Marc Zyngier (2): > arm64: Advertise mitigation of Spectre-v2, or lack thereof > arm64: Use firmware to detect CPUs that are not affected by Spectre-v2 > > Mian Yousaf Kaukab (2): > arm64: add sysfs vulnerability show for spectre v1 > arm64: enable generic CPU vulnerabilites support > > .../admin-guide/kernel-parameters.txt | 8 +- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/cpufeature.h | 4 - > arch/arm64/kernel/cpu_errata.c | 239 +++++++++++++----- > arch/arm64/kernel/cpufeature.c | 58 ++++- > 5 files changed, 223 insertions(+), 87 deletions(-) >
On Thu, Mar 21, 2019 at 06:05:47PM -0500, Jeremy Linton wrote: > Arm64 machines should be displaying a human readable > vulnerability status to speculative execution attacks in > /sys/devices/system/cpu/vulnerabilities > > This series enables that behavior by providing the expected > functions. Those functions expose the cpu errata and feature > states, as well as whether firmware is responding appropriately > to display the overall machine status. This means that in a > heterogeneous machine we will only claim the machine is mitigated > or safe if we are confident all booted cores are safe or > mitigated. > > v5->v6: > Invert meltdown logic to display that a core is safe rather > than mitigated if the mitigation has been enabled on > machines that are safe. This can happen when the > mitigation was forced on via command line or KASLR. > This means that in order to detect if kpti is enabled > other methods must be used (look at dmesg) when the > machine isn't itself susceptible to meltdown. > Trivial whitespace tweaks. The v6 logic looks fine to me. For the whole series: Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Arm64 machines should be displaying a human readable vulnerability status to speculative execution attacks in /sys/devices/system/cpu/vulnerabilities This series enables that behavior by providing the expected functions. Those functions expose the cpu errata and feature states, as well as whether firmware is responding appropriately to display the overall machine status. This means that in a heterogeneous machine we will only claim the machine is mitigated or safe if we are confident all booted cores are safe or mitigated. v5->v6: Invert meltdown logic to display that a core is safe rather than mitigated if the mitigation has been enabled on machines that are safe. This can happen when the mitigation was forced on via command line or KASLR. This means that in order to detect if kpti is enabled other methods must be used (look at dmesg) when the machine isn't itself susceptible to meltdown. Trivial whitespace tweaks. v4->v5: Revert the changes to remove the CONFIG_EXPERT hidden options, but leave the detection paths building without #ifdef wrappers. Also remove the CONFIG_GENERIC_CPU_VULNERABILITIES #ifdefs as we are 'select'ing the option in the Kconfig. This allows us to keep all three variations of the CONFIG/enable/disable paths without a lot of (CONFIG_X || CONFIG_Y) checks. Various bits/pieces moved between the patches in an attempt to keep similar features/changes together. v3->v4: Drop the patch which selectivly exports sysfs entries Remove the CONFIG_EXPERT hidden options which allowed the kernel to be built without the vulnerability detection code. Pick Marc Z's patches which invert the white/black lists for spectrev2 and clean up the firmware detection logic. Document the existing kpti controls Add a nospectre_v2 option to boot time disable the mitigation v2->v3: Remove "Unknown" states, replace with further blacklists and default vulnerable/not affected states. Add the ability for an arch port to selectively export sysfs vulnerabilities. v1->v2: Add "Unknown" state to ABI/testing docs. Minor tweaks. Jeremy Linton (6): arm64: Provide a command line to disable spectre_v2 mitigation arm64: add sysfs vulnerability show for meltdown arm64: Always enable spectrev2 vulnerability detection arm64: add sysfs vulnerability show for spectre v2 arm64: Always enable ssb vulnerability detection arm64: add sysfs vulnerability show for speculative store bypass Marc Zyngier (2): arm64: Advertise mitigation of Spectre-v2, or lack thereof arm64: Use firmware to detect CPUs that are not affected by Spectre-v2 Mian Yousaf Kaukab (2): arm64: add sysfs vulnerability show for spectre v1 arm64: enable generic CPU vulnerabilites support .../admin-guide/kernel-parameters.txt | 8 +- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/cpufeature.h | 4 - arch/arm64/kernel/cpu_errata.c | 239 +++++++++++++----- arch/arm64/kernel/cpufeature.c | 58 ++++- 5 files changed, 223 insertions(+), 87 deletions(-) -- 2.20.1