• Andi Kleen's avatar
    x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings · 9870e755
    Andi Kleen authored
    commit 42e4089c upstream.
    
    For L1TF PROT_NONE mappings are protected by inverting the PFN in the page
    table entry. This sets the high bits in the CPU's address space, thus
    making sure to point to not point an unmapped entry to valid cached memory.
    
    Some server system BIOSes put the MMIO mappings high up in the physical
    address space. If such an high mapping was mapped to unprivileged users
    they could attack low memory by setting such a mapping to PROT_NONE. This
    could happen through a special device driver which is not access
    protected. Normal /dev/mem is of course access protected.
    
    To avoid this forbid PROT_NONE mappings or mprotect for high MMIO mappings.
    
    Valid page mappings are allowed because the system is then unsafe anyways.
    
    It's not expected that users commonly use PROT_NONE on MMIO. But to
    minimize any impact this is only enforced if the mapping actually refers to
    a high MMIO address (defined as the MAX_PA-1 bit being set), and also skip
    the check for root.
    
    For mmaps this is straight forward and can be handled in vm_insert_pfn and
    in remap_pfn_range().
    
    For mprotect it's a bit trickier. At the point where the actual PTEs are
    accessed a lot of state has been changed and it would be difficult to undo
    on an error. Since this is a uncommon case use a separate early page talk
    walk pass for MMIO PROT_NONE mappings that checks for this condition
    early. For non MMIO and non PROT_NONE there are no changes.
    Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
    Acked-by: default avatarDave Hansen <dave.hansen@intel.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    9870e755