On Sun, 2023-02-19 at 12:43 -0800, Kees Cook wrote:

On Sat, Feb 18, 2023 at 01:14:17PM -0800, Rick Edgecombe wrote:

quoted

The x86 Control-flow Enforcement Technology (CET) feature includes
a new
type of memory called shadow stack. This shadow stack memory has
some
unusual properties, which require some core mm changes to function
properly.

One of the properties is that the shadow stack pointer (SSP), which
is a
CPU register that points to the shadow stack like the stack pointer
points
to the stack, can't be pointing outside of the 32 bit address space
when
the CPU is executing in 32 bit mode. It is desirable to prevent
executing
in 32 bit mode when shadow stack is enabled because the kernel
can't easily
support 32 bit signals.

On x86 it is possible to transition to 32 bit mode without any
special
interaction with the kernel, by doing a "far call" to a 32 bit
segment.
So the shadow stack implementation can use this address space
behavior
as a feature, by enforcing that shadow stack memory is always
crated
outside of the 32 bit address space. This way userspace will
trigger a
general protection fault which will in turn trigger a segfault if
it
tries to transition to 32 bit mode with shadow stack enabled.

This provides a clean error generating border for the user if they
try
attempt to do 32 bit mode shadow stack, rather than leave the
kernel in a
half working state for userspace to be surprised by.

So to allow future shadow stack enabling patches to map shadow
stacks
out of the 32 bit address space, introduce MAP_ABOVE4G. The
behavior
is pretty much like MAP_32BIT, except that it has the opposite
address
range. The are a few differences though.

If both MAP_32BIT and MAP_ABOVE4G are provided, the kernel will use
the
MAP_ABOVE4G behavior. Like MAP_32BIT, MAP_ABOVE4G is ignored in a
32 bit
syscall.

Should the interface refuse to accept both set instead?

I guess that might be less surprising. But I think to do this would
either require adding logic to core mm or a new arch breakout. I
actually kind of wish there was an easy way to keep this flag from
being used from userspace and just be a kernel only thing. It is only
used internally in this series and there isn't any know use for
userspace.

Reviewed-by: Kees Cook <redacted>