Thread (110 messages) 110 messages, 6 authors, 2024-08-21

Re: [PATCH v10 04/40] arm64: Document boot requirements for Guarded Control Stacks

From: Mark Brown <broonie@kernel.org>
Date: 2024-08-15 18:14:10
Also in: kvmarm, linux-arch, linux-arm-kernel, linux-fsdevel, linux-kselftest, linux-mm, linux-riscv, lkml

On Thu, Aug 15, 2024 at 06:00:15PM +0100, Catalin Marinas wrote:
On Thu, Aug 01, 2024 at 01:06:31PM +0100, Mark Brown wrote:
quoted
+  - If EL2 is present:
quoted
+    - GCSCR_EL2 must be initialised to 0.
quoted
+ - If the kernel is entered at EL1 and EL2 is present:
+
+    - GCSCR_EL1 must be initialised to 0.
+
+    - GCSCRE0_EL1 must be initialised to 0.
Currently booting.rst doesn't list *_EL1 registers to be initialised
when the kernel is entered at EL1, that would usually be the
responsibility of EL1. The exception is some bits in SCTLR_EL1 around
not entering with the MMU and caches enabled. But here I think it makes
sense to add these GCS registers since if some random bits are set, they
can affect kernels (and user apps) that don't have GCS support.
Right, exactly - the trouble here is that if we enter EL1 with GCS
enabled we aren't able to do function calls until we either disable GCS
or configure the MMU and allocate a GCS.  This means that all existing
kernels which haven't heard of GCS require that GCS be disabled prior to
starting, they'll just fault within a couple of instructions whenever
they reach the EL for which GCS is enabled so it seems sensible to just
require that this is set up.  It is hard to envision a scenario in which
it would be reasonable to start in a different configuration.

Now I think about it I should move those two to not depend on EL2 being
present, that's just cut'n'paste.
Don't we need HCRX_EL2.GCSEn to be set when entered at EL1?
Yes, if we want GCS to do anything.  I've added this.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help