• D
    x86/mm/mpx: Work around MPX erratum SKD046 · 0f6ff2bc
    Dave Hansen 提交于
    This erratum essentially causes the CPU to forget which privilege
    level it is operating on (kernel vs. user) for the purposes of MPX.
    
    This erratum can only be triggered when a system is not using
    Supervisor Mode Execution Prevention (SMEP).  Our workaround for
    the erratum is to ensure that MPX can only be used in cases where
    SMEP is present in the processor and is enabled.
    
    This erratum only affects Core processors.  Atom is unaffected.
    But, there is no architectural way to determine Atom vs. Core.
    So, we just apply this workaround to all processors.  It's
    possible that it will mistakenly disable MPX on some Atom
    processsors or future unaffected Core processors.  There are
    currently no processors that have MPX and not SMEP.  It would
    take something akin to a hypervisor masking SMEP out on an Atom
    processor for this to present itself on current hardware.
    
    More details can be found at:
    
      http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf
    
    "
      SKD046 Branch Instructions May Initialize MPX Bound Registers Incorrectly
    
      Problem:
    
      Depending on the current Intel MPX (Memory Protection
      Extensions) configuration, execution of certain branch
      instructions (near CALL, near RET, near JMP, and Jcc
      instructions) without a BND prefix (F2H) initialize the MPX bound
      registers. Due to this erratum, such a branch instruction that is
      executed both with CPL = 3 and with CPL < 3 may not use the
      correct MPX configuration register (BNDCFGU or BNDCFGS,
      respectively) for determining whether to initialize the bound
      registers; it may thus initialize the bound registers when it
      should not, or fail to initialize them when it should.
    
      Implication:
    
      A branch instruction that has executed both in user mode and in
      supervisor mode (from the same linear address) may cause a #BR
      (bound range fault) when it should not have or may not cause a
      #BR when it should have.  Workaround An operating system can
      avoid this erratum by setting CR4.SMEP[bit 20] to enable
      supervisor-mode execution prevention (SMEP). When SMEP is
      enabled, no code can be executed both with CPL = 3 and with CPL < 3.
    "
    Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave@sr71.net>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20160512220400.3B35F1BC@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
    0f6ff2bc
common.c 38.1 KB