On Thu, Aug 08, 2024 at 09:15:21AM +0100, Mark Brown wrote: > The kernel has recently added support for shadow stacks, currently > x86 only using their CET feature but both arm64 and RISC-V have > equivalent features (GCS and Zicfiss respectively), I am actively > working on GCS[1]. With shadow stacks the hardware maintains an > additional stack containing only the return addresses for branch > instructions which is not generally writeable by userspace and ensures > that any returns are to the recorded addresses. This provides some > protection against ROP attacks and making it easier to collect call > stacks. These shadow stacks are allocated in the address space of the > userspace process. > > Our API for shadow stacks does not currently offer userspace any > flexiblity for managing the allocation of shadow stacks for newly > created threads, instead the kernel allocates a new shadow stack with > the same size as the normal stack whenever a thread is created with the > feature enabled. The stacks allocated in this way are freed by the > kernel when the thread exits or shadow stacks are disabled for the > thread. This lack of flexibility and control isn't ideal, in the vast > majority of cases the shadow stack will be over allocated and the > implicit allocation and deallocation is not consistent with other > interfaces. As far as I can tell the interface is done in this manner > mainly because the shadow stack patches were in development since before > clone3() was implemented. > > Since clone3() is readily extensible let's add support for specifying a > shadow stack when creating a new thread or process in a similar manner > to how the normal stack is specified, keeping the current implicit > allocation behaviour if one is not specified either with clone3() or > through the use of clone(). The user must provide a shadow stack > address and size, this must point to memory mapped for use as a shadow > stackby map_shadow_stack() with a shadow stack token at the top of the > stack. > > Please note that the x86 portions of this code are build tested only, I > don't appear to have a system that can run CET avaible to me, I have > done testing with an integration into my pending work for GCS. There is > some possibility that the arm64 implementation may require the use of > clone3() and explicit userspace allocation of shadow stacks, this is > still under discussion. > > Please further note that the token consumption done by clone3() is not > currently implemented in an atomic fashion, Rick indicated that he would > look into fixing this if people are OK with the implementation. > > A new architecture feature Kconfig option for shadow stacks is added as > here, this was suggested as part of the review comments for the arm64 > GCS series and since we need to detect if shadow stacks are supported it > seemed sensible to roll it in here. > > [1] https://lore.kernel.org/r/20231009-arm64-gcs-v6-0-78e55deaa4dd@xxxxxxxxxx/ > > Signed-off-by: Mark Brown <broonie@xxxxxxxxxx> Reviewed-by: Kees Cook <kees@xxxxxxxxxx> Tested-by: Kees Cook <kees@xxxxxxxxxx> (Testing was done on CET hardware.) -- Kees Cook
