• Gerald Schaefer's avatar
    [S390] noexec protection · c1821c2e
    Gerald Schaefer authored
    This provides a noexec protection on s390 hardware. Our hardware does
    not have any bits left in the pte for a hw noexec bit, so this is a
    different approach using shadow page tables and a special addressing
    mode that allows separate address spaces for code and data.
    
    As a special feature of our "secondary-space" addressing mode, separate
    page tables can be specified for the translation of data addresses
    (storage operands) and instruction addresses. The shadow page table is
    used for the instruction addresses and the standard page table for the
    data addresses.
    The shadow page table is linked to the standard page table by a pointer
    in page->lru.next of the struct page corresponding to the page that
    contains the standard page table (since page->private is not really
    private with the pte_lock and the page table pages are not in the LRU
    list).
    Depending on the software bits of a pte, it is either inserted into
    both page tables or just into the standard (data) page table. Pages of
    a vma that does not have the VM_EXEC bit set get mapped only in the
    data address space. Any try to execute code on such a page will cause a
    page translation exception. The standard reaction to this is a SIGSEGV
    with two exceptions: the two system call opcodes 0x0a77 (sys_sigreturn)
    and 0x0aad (sys_rt_sigreturn) are allowed. They are stored by the
    kernel to the signal stack frame. Unfortunately, the signal return
    mechanism cannot be modified to use an SA_RESTORER because the
    exception unwinding code depends on the system call opcode stored
    behind the signal stack frame.
    
    This feature requires that user space is executed in secondary-space
    mode and the kernel in home-space mode, which means that the addressing
    modes need to be switched and that the noexec protection only works
    for user space.
    After switching the addressing modes, we cannot use the mvcp/mvcs
    instructions anymore to copy between kernel and user space. A new
    mvcos instruction has been added to the z9 EC/BC hardware which allows
    to copy between arbitrary address spaces, but on older hardware the
    page tables need to be walked manually.
    Signed-off-by: default avatarGerald Schaefer <geraldsc@de.ibm.com>
    Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    c1821c2e
tlbflush.h 3.66 KB