lkml.org 
[lkml]   [2018]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Yet another KPTI regression with 4.14.x series in a VM
    On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote:
    > Now this is quite a strange value to write to CR3. The 0x800 part
    > means that we're using the "user" variant of the address space that
    > would have ASID=0 and the 0x1000 bit being set corresponds to the user
    > pgdir, but this is nonsense, since the kernel never uses PCID 0 for
    > user mode. We always start at 1. The only exception is if
    > X86_FEATURE_PCID is off. But, if X86_FEATURE_PCID is off, then we
    > shouldn't be setting any PCID bits.

    My bad, I was under the impression the lower 12 bits would be ignored
    without PCID :/

    > .Lwrcr3_\@:
    > /* Flip the PGD and ASID to the user version */
    > orq $(PTI_SWITCH_MASK), \scratch_reg
    > mov \scratch_reg, %cr3
    > .Lend_\@:
    >
    > That's bogus. PTI_SWITCH_MASK is 0x1800, which has PCID = 0x800.

    > This should probably use an alternative to select between 0x1000 and
    > 0x800 depending on X86_FEATURE_PCID or just use an entirely different
    > label for the !PCID case.

    ALTERNATIVE "orq $(PTI_SWITCH_PGTABLE_MASK), \scratch_reg",
    "orq $(PTI_SWITCH_MASK), \scratch_reg", X86_FEATURE_PCID

    Is not wanting to compile though; probably that whole alternative vs
    macro thing again :/


    \
     
     \ /
      Last update: 2018-01-14 23:26    [W:5.621 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site