On Mon, Aug 07, 2023 at 11:00:08PM +0100, Mark Brown wrote:
+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.
+* 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/
+* 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?
+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?
+* 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?
+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.