Re: [PATCH v4 03/36] arm64/gcs: Document the ABI for Guarded Control Stacks
From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2023-08-09 14:24:25
Also in:
kvmarm, linux-arch, linux-doc, linux-fsdevel, linux-kselftest, linux-mm, linux-riscv, lkml
On Mon, Aug 07, 2023 at 11:00:08PM +0100, Mark Brown wrote:
quoted hunk ↗ jump to hunk
+2. Enabling and disabling Guarded Control Stacks +------------------------------------------------- + +* GCS is enabled and disabled for a thread via the PR_SET_SHADOW_STACK_STATUS + prctl(), this takes a single flags argument specifying which GCS features + should be used. + +* When set PR_SHADOW_STACK_ENABLE flag allocates a Guarded Control Stack for
The 'for' at the end of the line above is not needed.
+ and enables GCS for the thread, enabling the functionality controlled by
+ GCSPRE0_EL1.{nTR, RVCHKEN, PCRSEL}.This should be GCSCRE0_EL1.
quoted hunk ↗ jump to hunk
+* When set the PR_SHADOW_STACK_PUSH flag enables the functionality controlled + by GCSCRE0_EL1.PUSHMEn, allowing explicit GCS pushes. + +* When set the PR_SHADOW_STACK_WRITE flag enables the functionality controlled + by GCSCRE0_EL1.STREn, allowing explicit stores to the Guarded Control Stack. + +* Any unknown flags will cause PR_SET_SHADOW_STACK_STATUS to return -EINVAL. + +* PR_LOCK_SHADOW_STACK_STATUS is passed a bitmask of features with the same + values as used for PR_SET_SHADOW_STACK_STATUS. Any future changes to the + status of the specified GCS mode bits will be rejected. + +* PR_LOCK_SHADOW_STACK_STATUS allows any bit to be locked, this allows + userspace to prevent changes to any future features.
I presume a new lock prctl() won't allow unlocking but can only extend the lock. I haven't looked at the patches yet but it may be worth spelling this out.
+* PR_SET_SHADOW_STACK_STATUS and PR_LOCK_SHADOW_STACK_STATUS affect only the + thread the called them, any other running threads will be unaffected.
s/the called/that called/
quoted hunk ↗ jump to hunk
+* New threads inherit the GCS configuration of the thread that created them. + +* GCS is disabled on exec(). + +* The current GCS configuration for a thread may be read with the + PR_GET_SHADOW_STACK_STATUS prctl(), this returns the same flags that + are passed to PR_SET_SHADOW_STACK_STATUS. + +* If GCS is disabled for a thread after having previously been enabled then + the stack will remain allocated for the lifetime of the thread.
Sorry if this has been discussed in other threads. What is the issue with unmapping/freeing of the shadow stack?
At present + any attempt to reenable GCS for the thread will be rejected, this may be + revisited in future.
What's the rationale here? Is it that function returns won't work?
quoted hunk ↗ jump to hunk
+3. Allocation of Guarded Control Stacks +---------------------------------------- + +* When GCS is enabled for a thread a new Guarded Control Stack will be + allocated for it of size RLIMIT_STACK / 2 or 2 gigabytes, whichever is + smaller.
Is this number based on the fact that a function call would only push the LR to GCS while standard function prologue pushes at least two registers?
quoted hunk ↗ jump to hunk
+* When GCS is disabled for a thread the Guarded Control Stack initially + allocated for that thread will be freed. Note carefully that if the + stack has been switched this may not be the stack currently in use by + the thread.
Does this not contradict an earlier statement that the GCS is not freed for a thread when disabled?
quoted hunk ↗ jump to hunk
+4. Signal handling +-------------------- + +* A new signal frame record gcs_context encodes the current GCS mode and + pointer for the interrupted context on signal delivery. This will always + be present on systems that support GCS. + +* The record contains a flag field which reports the current GCS configuration + for the interrupted context as PR_GET_SHADOW_STACK_STATUS would. + +* The signal handler is run with the same GCS configuration as the interrupted + context. + +* When GCS is enabled for the interrupted thread a signal handling specific + GCS cap token will be written to the GCS, this is an architectural GCS cap + token with bit 63 set. The GCSPR_EL0 reported in the signal frame will + point to this cap token.
I lost track of the GCS spec versions. Has the valid cap token format been updated? What I have in my spec (though most likely old) is: An entry in the Guarded control stack is defined as a Valid cap entry, if bits [63:12] of the value are same as bits [63:12] of the address where the entry is stored and bits [11:0] contain a Valid cap token. The other bits in the code look fine to me so far but I haven't looked at the code yet. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel