On 1/17/20 12:00 PM, Catalin Marinas wrote:

On Fri, Jan 17, 2020 at 04:13:06PM +0530, Amit Kachhap wrote:

quoted

On 1/16/20 9:54 PM, Catalin Marinas wrote:

quoted

On Mon, Dec 16, 2019 at 02:17:08PM +0530, Amit Daniel Kachhap wrote:

quoted

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 5aaf1bb..c59c28f 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S

[...]

quoted

quoted

quoted

+ENTRY(__cpu_secondary_checkptrauth)
+#ifdef CONFIG_ARM64_PTR_AUTH
+	/* Check if the CPU supports ptrauth */
+	mrs	x2, id_aa64isar1_el1
+	ubfx	x2, x2, #ID_AA64ISAR1_APA_SHIFT, #8
+	cbnz	x2, 1f
+alternative_if ARM64_HAS_ADDRESS_AUTH
+	mov	x3, 1
+alternative_else
+	mov	x3, 0
+alternative_endif
+	cbz	x3, 1f
+	/* Park the mismatched secondary CPU */
+	early_park_cpu CPU_STUCK_REASON_NO_PTRAUTH
+#endif
+1:	ret
+ENDPROC(__cpu_secondary_checkptrauth)

Do we actually need to park secondary CPUs early? Let's say a secondary
CPU doesn't have PAC, __cpu_setup won't set the corresponding SCTLR_EL1
bits and the instructions are NOPs. Wouldn't the cpufeature framework
park it later anyway?

In the current cpufeature framework, such missing cpufeature in
secondary cpu will lead to kernel panic (inside check_early_cpufeatures)
and not cpu offline. However Kristina in her RFC V2 [1] added such
feature to park it.

I remember discussing how to avoid the kernel panic with her at the
time.

quoted

Later for moving the enabling ptrauth to assembly this work got dropped.
Suzuki provided the template code for doing that [2].

Later James suggested to do this like existing
__cpu_secondary_check52bitva which parks the secondary cpu very early
and also to save wasted cpu cycles [3].

I don't really care about a few cycles lost during boot.

quoted

So your question is still valid that it can be done in cpufeature. Let
me know your opinion that which one is better.

My preference is for Kristina's approach. The 52-bit VA is slightly
different (as is VHE) as we cannot guarantee the secondary CPU to even
reach the CPU framework. With PAC, I don't see why it would fail
reaching the C code, so I'd prefer a more readable C implementation than
the assembler one.

ok. I will use approach in my next iteration.

Anyway, I'm open to counterarguments here.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel