[PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Thank you,

Best regards,
Yousaf

Mian Yousaf Kaukab (6):
  arm64: kpti: move check for non-vulnerable CPUs to a function
  arm64: add sysfs vulnerability show for meltdown
  arm64: add sysfs vulnerability show for spectre v1
  arm64: add sysfs vulnerability show for spectre v2
  arm64: add sysfs vulnerability show for speculative store bypass
  arm64: enable generic CPU vulnerabilites support

 arch/arm64/Kconfig                  |  1 +
 arch/arm64/include/asm/cpufeature.h | 16 +++++++
 arch/arm64/kernel/cpu_errata.c      | 84 ++++++++++++++++++++++++++++++++++++-
 arch/arm64/kernel/cpufeature.c      |  9 +---
 4 files changed, 101 insertions(+), 9 deletions(-)

-- 
2.11.0

Checking CSV3 support directly in case CONFIG_UNMAP_KERNEL_AT_EL0
is not enabled.

Signed-off-by: Mian Yousaf Kaukab <redacted>
---
 arch/arm64/kernel/cpu_errata.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index dec10898d688..996edb4e18ad 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c

@@ -22,6 +22,7 @@
 #include <asm/cpu.h>
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
+#include <asm/mmu.h>
 
 static bool __maybe_unused
 is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int scope)

@@ -683,3 +684,26 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 	{
 	}
 };
+
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
+		char *buf)
+{
+	u64 pfr0;
+	u32 csv3;
+
+	if (arm64_kernel_unmapped_at_el0())
+		return sprintf(buf, "Mitigation: KPTI\n");
+
+	pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+	csv3 = cpuid_feature_extract_unsigned_field(pfr0,
+			ID_AA64PFR0_CSV3_SHIFT);
+
+	if (csv3 || is_cpu_meltdown_safe())
+		return sprintf(buf, "Not affected\n");
+
+	return sprintf(buf, "Vulnerable\n");
+}
+
+#endif

-- 
2.11.0

Only report mitigation present if hardening callback has been
successfully installed.

Signed-off-by: Mian Yousaf Kaukab <redacted>
---
 arch/arm64/kernel/cpu_errata.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 92616431ae4e..8469d3be7b15 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c

@@ -481,7 +481,8 @@ multi_entry_cap_cpu_enable(const struct arm64_cpu_capabilities *entry)
 			caps->cpu_enable(caps);
 }
 
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+#if defined(CONFIG_HARDEN_BRANCH_PREDICTOR) || \
+	defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
 
 /*
  * List of CPUs where we need to issue a psci call to

@@ -712,4 +713,35 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
 	return sprintf(buf, "Mitigation: __user pointer sanitization\n");
 }
 
+ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
+		char *buf)
+{
+	u64 pfr0;
+	struct bp_hardening_data *data;
+
+	pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+	if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_CSV2_SHIFT))
+		return sprintf(buf, "Not affected\n");
+
+	if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
+		/*
+		 * Hardware is vulnerable. Lets check if bp hardening callback
+		 * has been successfully installed
+		 */
+		data = arm64_get_bp_hardening_data();
+		if (data && data->fn)
+			return sprintf(buf,
+				"Mitigation: Branch predictor hardening");
+		else
+			/* For example SMCCC_VERSION_1_0 */
+			return sprintf(buf, "Vulnerable\n");
+	}
+
+	/* In case CONFIG_HARDEN_BRANCH_PREDICTOR is not enabled */
+	if (is_midr_in_range_list(read_cpuid_id(), arm64_bp_harden_smccc_cpus))
+		return sprintf(buf, "Vulnerable\n");
+
+	return sprintf(buf, "Not affected\n");
+}
+
 #endif

-- 
2.11.0

Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
meltdown and store-bypass.

Signed-off-by: Mian Yousaf Kaukab <redacted>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0dec01a0c81c..ffd97bc0f5d5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig

@@ -84,6 +84,7 @@ config ARM64
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_CLOCKEVENTS_BROADCAST
 	select GENERIC_CPU_AUTOPROBE
+	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_EARLY_IOREMAP
 	select GENERIC_IDLE_POLL_SETUP
 	select GENERIC_IRQ_MULTI_HANDLER

-- 
2.11.0

Return status based no ssbd_state. Return string "Unknown" in case
CONFIG_ARM64_SSBD is disabled or arch workaround2 is not available
in the firmware.

Signed-off-by: Mian Yousaf Kaukab <redacted>
---
 arch/arm64/kernel/cpu_errata.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8469d3be7b15..8b60aa30a3fa 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c

@@ -744,4 +744,24 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
 	return sprintf(buf, "Not affected\n");
 }
 
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	switch (arm64_get_ssbd_state()) {
+	case ARM64_SSBD_MITIGATED:
+		return sprintf(buf, "Not affected\n");
+
+	case ARM64_SSBD_KERNEL:
+	case ARM64_SSBD_FORCE_ENABLE:
+		return sprintf(buf,
+			"Mitigation: Speculative Store Bypass disabled");
+
+	case ARM64_SSBD_FORCE_DISABLE:
+		return sprintf(buf, "Vulnerable\n");
+
+	default: /* ARM64_SSBD_UNKNOWN*/
+		return sprintf(buf, "Unknown\n");
+	}
+}
+
 #endif

-- 
2.11.0

Prepare to call it in generic cpu vulnerabilities support.

Signed-off-by: Mian Yousaf Kaukab <redacted>
---
 arch/arm64/include/asm/cpufeature.h | 16 ++++++++++++++++
 arch/arm64/kernel/cpufeature.c      |  9 +--------
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 1717ba1db35d..0b0b5b3e36ba 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h

@@ -530,6 +530,22 @@ void arm64_set_ssbd_mitigation(bool state);
 static inline void arm64_set_ssbd_mitigation(bool state) {}
 #endif
 
+static inline bool is_cpu_meltdown_safe(void)
+{
+	/* List of CPUs that are not vulnerable and don't need KPTI */
+	static const struct midr_range kpti_safe_list[] = {
+		MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
+		MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
+		{ /* sentinel */ }
+	};
+
+	/* Don't force KPTI for CPUs that are not vulnerable */
+	if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+		return true;
+
+	return false;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e238b7932096..6a94f8bce35a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c

@@ -865,12 +865,6 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
 static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
 				int scope)
 {
-	/* List of CPUs that are not vulnerable and don't need KPTI */
-	static const struct midr_range kpti_safe_list[] = {
-		MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
-		MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
-		{ /* sentinel */ }
-	};
 	char const *str = "command line option";
 
 	/*

@@ -894,8 +888,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
 	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
 		return true;
 
-	/* Don't force KPTI for CPUs that are not vulnerable */
-	if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+	if (is_cpu_meltdown_safe())
 		return false;
 
 	/* Defer to CPU feature registers */

-- 
2.11.0

Hard-coded since patches are merged and there are no configuration
options.

Signed-off-by: Mian Yousaf Kaukab <redacted>
---
 arch/arm64/kernel/cpu_errata.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 996edb4e18ad..92616431ae4e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c

@@ -706,4 +706,10 @@ ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
 	return sprintf(buf, "Vulnerable\n");
 }
 
+ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
+		char *buf)
+{
+	return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+}
+
 #endif

-- 
2.11.0

On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Marc, Will, Can you please review this series?
Please let me know if I should rebase it against arm64 tree.

Thanks,
Yousaf

On Mon, Aug 27, 2018 at 04:33:06PM +0200, Mian Yousaf Kaukab wrote:

This should say something like "Unknown", since we don't actually have a
reliable way to determine that a CPU is vulnerable. That's also a large
part of the reason why we haven't bothered implementing the sysfs interface
so far.

Will

On Mon, Aug 27, 2018 at 04:33:08PM +0200, Mian Yousaf Kaukab wrote:

This strikes me as a pretty terrible interface, as it means that the file
can return different contents depending on which CPU it was read from on a
big/little machine. I think we need to either expose this per-cpu, or expose
the value of the system (e.g. if one CPU is vulnerable, we always say
vulnerable).

+
+	if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
+		/*
+		 * Hardware is vulnerable. Lets check if bp hardening callback
+		 * has been successfully installed
+		 */
+		data = arm64_get_bp_hardening_data();

Related to the above, but this is accessing per-cpu stuff.

Will

On Mon, Aug 27, 2018 at 04:33:09PM +0200, Mian Yousaf Kaukab wrote:

This probably wants extending for CPUs that support SSBS (see
for-next/core).

Will

On Wed, Sep 05, 2018 at 11:25:33AM +0200, Mian Yousaf Kaukab wrote:

On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:

quoted

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Marc, Will, Can you please review this series?

Sorry it took so long to get to this, it's just consistently failed to
get to the top of my review queue. I had a quick look just now and there
are a few things to address before we can take the series.

Cheers,

Will

On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:

Hard-coded since patches are merged and there are no configuration
options.

Could you add a list of upstream patches to the description that are
required to solve this? This would be a strict definition for the
mitigation being enabled and makes it easier to check if backports are
affected or not. A build-time check would be ideal (e.g. checking for
certain macros).

Looking at arm64/kpti I see the following patches:

f84a56f73ddd^..f3804203306e 669474e772b9^..91b2d3442f6a

v4.16-rc1  f84a56f73ddd Documentation: Document array_index_nospec
v4.16-rc1  f3804203306e array_index_nospec: Sanitize speculative array de-references
v4.16-rc1  669474e772b9 arm64: barrier: Add CSDB macros to control data-value prediction
v4.16-rc1  022620eed3d0 arm64: Implement array_index_mask_nospec()
v4.16-rc1  51369e398d0d arm64: Make USER_DS an inclusive limit
v4.16-rc1  4d8efc2d5ee4 arm64: Use pointer masking to limit uaccess speculation
v4.16-rc1  6314d90e6493 arm64: entry: Ensure branch through syscall table is bounded under speculation
v4.16-rc1  c2f0ad4fc089 arm64: uaccess: Prevent speculative use of the current addr_limit
v4.16-rc1  84624087dd7e arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user
v4.16-rc1  f71c2ffcb20d arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
v4.16-rc1  91b2d3442f6a arm64: futex: Mask __user pointers prior to dereference

-Robert

On Mon, Sep 17, 2018 at 07:22:07PM +0200, Robert Richter wrote:

On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:

quoted

Hard-coded since patches are merged and there are no configuration
options.

Could you add a list of upstream patches to the description that are
required to solve this? This would be a strict definition for the
mitigation being enabled and makes it easier to check if backports are
affected or not. A build-time check would be ideal (e.g. checking for
certain macros).

Hmm, I don't grok what you're proposing here. Why do we need a build-time
check (and to check what?)

Confused,

Will

On 18.09.18 09:38:05, Will Deacon wrote:

On Mon, Sep 17, 2018 at 07:22:07PM +0200, Robert Richter wrote:

quoted

On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:

quoted

Hard-coded since patches are merged and there are no configuration
options.

Could you add a list of upstream patches to the description that are
required to solve this? This would be a strict definition for the
mitigation being enabled and makes it easier to check if backports are
affected or not. A build-time check would be ideal (e.g. checking for
certain macros).

Hmm, I don't grok what you're proposing here. Why do we need a build-time
check (and to check what?)

My concern is, that for kernel backports (esp. distro kernels) there
could be various interpretations of what "Mitigation: __user pointer
sanitization" means. So a list of upstream patches that need to be
backported in addition to this patch as a requirement would be good to
agree on. That should be documented in the patch description.

If these mitigations are available in a kernel backport, that could be
even checked at build time. E.g. we could have a sanity check if the
macro array_index_nospec() is defined. But such a check does not
replace a code review of a kernel backport.

I hope that makes sense?

-Robert

On Tue, Sep 18, 2018 at 11:52:27AM +0200, Robert Richter wrote:

On 18.09.18 09:38:05, Will Deacon wrote:

quoted

On Mon, Sep 17, 2018 at 07:22:07PM +0200, Robert Richter wrote:

quoted

On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:

quoted

Hard-coded since patches are merged and there are no configuration
options.

Could you add a list of upstream patches to the description that are
required to solve this? This would be a strict definition for the
mitigation being enabled and makes it easier to check if backports are
affected or not. A build-time check would be ideal (e.g. checking for
certain macros).

Hmm, I don't grok what you're proposing here. Why do we need a build-time
check (and to check what?)

My concern is, that for kernel backports (esp. distro kernels) there
could be various interpretations of what "Mitigation: __user pointer
sanitization" means. So a list of upstream patches that need to be
backported in addition to this patch as a requirement would be good to
agree on. That should be documented in the patch description.

If these mitigations are available in a kernel backport, that could be
even checked at build time. E.g. we could have a sanity check if the
macro array_index_nospec() is defined. But such a check does not
replace a code review of a kernel backport.

I hope that makes sense?

Ok, I see what you mean now, thanks. However, it doesn't sound much
different than backporting a patch with dependencies, so I'd rather
avoid adding additional code to treat this case specially.

Will

On 18.09.18 18:15:51, Will Deacon wrote:

On Tue, Sep 18, 2018 at 11:52:27AM +0200, Robert Richter wrote:

quoted

On 18.09.18 09:38:05, Will Deacon wrote:

quoted

On Mon, Sep 17, 2018 at 07:22:07PM +0200, Robert Richter wrote:

quoted

On 27.08.18 16:33:07, Mian Yousaf Kaukab wrote:

quoted

Hard-coded since patches are merged and there are no configuration
options.

Could you add a list of upstream patches to the description that are
required to solve this? This would be a strict definition for the
mitigation being enabled and makes it easier to check if backports are
affected or not. A build-time check would be ideal (e.g. checking for
certain macros).

Hmm, I don't grok what you're proposing here. Why do we need a build-time
check (and to check what?)

My concern is, that for kernel backports (esp. distro kernels) there
could be various interpretations of what "Mitigation: __user pointer
sanitization" means. So a list of upstream patches that need to be
backported in addition to this patch as a requirement would be good to
agree on. That should be documented in the patch description.

If these mitigations are available in a kernel backport, that could be
even checked at build time. E.g. we could have a sanity check if the
macro array_index_nospec() is defined. But such a check does not
replace a code review of a kernel backport.

I hope that makes sense?

Ok, I see what you mean now, thanks. However, it doesn't sound much
different than backporting a patch with dependencies, so I'd rather
avoid adding additional code to treat this case specially.

A pointer to the patches would be helpful as the dependencies are not
obvious. This is different to just backport a complete series of
patches.

-Robert

On Mon, Sep 17, 2018 at 02:35:08PM +0100, Will Deacon wrote:

On Wed, Sep 05, 2018 at 11:25:33AM +0200, Mian Yousaf Kaukab wrote:

quoted

On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:

quoted

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Marc, Will, Can you please review this series?

Sorry it took so long to get to this, it's just consistently failed to
get to the top of my review queue. I had a quick look just now and there
are a few things to address before we can take the series.

Thank you for the review. I will get back to you after fixing the comments as soon as possible.

Cheers,

Will

Thanks,
Yousaf