lkml.org 
[lkml]   [2023]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v6 25/41] x86/mm: Introduce MAP_ABOVE4G
    Date
    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:
    > > 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 <keescook@chromium.org>
    \
     
     \ /
      Last update: 2023-03-27 00:29    [W:4.272 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site