Re: [v7 00/10] arm64: add system vulnerability sysfs entries

[Jeremy Linton <jeremy.linton@arm.com>]

Hi,

This patch has a bug, and I think i'm going to tweak patch 9 to drop the 
tristate (and default to a bool that is not vulnerable) since I ended up 
adding all those extra return checks to deal with the unresponsive 
firmware case.



On 4/10/19 6:12 PM, 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.
> 
> v6->v7: Invert ssb white/black list logic so that we only mark
> 	       cores in the whitelist not affected when the firmware
> 	       fails to respond. Removed reviewed/tested tags for
> 	       just patch 9 because of this.
> 
> 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                | 257 +++++++++++++-----
>   arch/arm64/kernel/cpufeature.c                |  58 +++-
>   5 files changed, 241 insertions(+), 87 deletions(-)
>