• Aruna Ramakrishna's avatar
    x86/pkeys: Add PKRU as a parameter in signal handling functions · 24cf2bc9
    Aruna Ramakrishna authored
    Assume there's a multithreaded application that runs untrusted user
    code. Each thread has its stack/code protected by a non-zero PKEY, and the
    PKRU register is set up such that only that particular non-zero PKEY is
    enabled. Each thread also sets up an alternate signal stack to handle
    signals, which is protected by PKEY zero. The PKEYs man page documents that
    the PKRU will be reset to init_pkru when the signal handler is invoked,
    which means that PKEY zero access will be enabled.  But this reset happens
    after the kernel attempts to push fpu state to the alternate stack, which
    is not (yet) accessible by the kernel, which leads to a new SIGSEGV being
    sent to the application, terminating it.
    
    Enabling both the non-zero PKEY (for the thread) and PKEY zero in
    userspace will not work for this use case. It cannot have the alt stack
    writeable by all - the rationale here is that the code running in that
    thread (using a non-zero PKEY) is untrusted and should not have access
    to the alternate signal stack (that uses PKEY zero), to prevent the
    return address of a function from being changed. The expectation is that
    kernel should be able to set up the alternate signal stack and deliver
    the signal to the application even if PKEY zero is explicitly disabled
    by the application. The signal handler accessibility should not be
    dictated by whatever PKRU value the thread sets up.
    
    The PKRU register is managed by XSAVE, which means the sigframe contents
    must match the register contents - which is not the case here. It's
    required that the signal frame contains the user-defined PKRU value (so
    that it is restored correctly from sigcontext) but the actual register must
    be reset to init_pkru so that the alt stack is accessible and the signal
    can be delivered to the application. It seems that the proper fix here
    would be to remove PKRU from the XSAVE framework and manage it separately,
    which is quite complicated. As a workaround, do this:
    
            orig_pkru = rdpkru();
            wrpkru(orig_pkru & init_pkru_value);
            xsave_to_user_sigframe();
            put_user(pkru_sigframe_addr, orig_pkru)
    
    In preparation for writing PKRU to sigframe, pass PKRU as an additional
    parameter down the call chain from get_sigframe().
    
    No functional change.
    Signed-off-by: default avatarAruna Ramakrishna <aruna.ramakrishna@oracle.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/all/20240802061318.2140081-2-aruna.ramakrishna@oracle.com
    24cf2bc9
signal.h 1.08 KB