• Hugh Dickins's avatar
    kaiser: PCID 0 for kernel and 128 for user · 5f2c43d8
    Hugh Dickins authored
    Why was 4 chosen for kernel PCID and 6 for user PCID?
    No good reason in a backport where PCIDs are only used for Kaiser.
    
    If we continue with those, then we shall need to add Andy Lutomirski's
    4.13 commit 6c690ee1 ("x86/mm: Split read_cr3() into read_cr3_pa()
    and __read_cr3()"), which deals with the problem of read_cr3() callers
    finding stray bits in the cr3 that they expected to be page-aligned;
    and for hibernation, his 4.14 commit f34902c5 ("x86/hibernate/64:
    Mask off CR3's PCID bits in the saved CR3").
    
    But if 0 is used for kernel PCID, then there's no need to add in those
    commits - whenever the kernel looks, it sees 0 in the lower bits; and
    0 for kernel seems an obvious choice.
    
    And I naughtily propose 128 for user PCID.  Because there's a place
    in _SWITCH_TO_USER_CR3 where it takes note of the need for TLB FLUSH,
    but needs to reset that to NOFLUSH for the next occasion.  Currently
    it does so with a "movb $(0x80)" into the high byte of the per-cpu
    quadword, but that will cause a machine without PCID support to crash.
    Now, if %al just happened to have 0x80 in it at that point, on a
    machine with PCID support, but 0 on a machine without PCID support...
    
    (That will go badly wrong once the pgd can be at a physical address
    above 2^56, but even with 5-level paging, physical goes up to 2^52.)
    Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    CVE-2017-5754
    Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
    Signed-off-by: default avatarKleber Sacilotto de Souza <kleber.souza@canonical.com>
    5f2c43d8
kaiser.h 4.02 KB