Skip to content
Permalink
Branch: odroidc2-v3.16…
Commits on Jun 18, 2019
  1. Merge tag 'v3.16.68' of git://git.kernel.org/pub/scm/linux/kernel/git…

    mdrjr committed Jun 18, 2019
    …/stable/linux-stable into odroidc2-v3.16.y
    
    This is the 3.16.68 stable release
Commits on Jun 12, 2019
  1. display: Add a new hdmi resolution, 480x272p60hz

    Joy Cho
    Joy Cho committed Jun 11, 2019
    Change-Id: Id3ed147f5586998e93947e8acffb173accfc7b4c
Commits on May 22, 2019
  1. Linux 3.16.68

    bwhacks committed May 22, 2019
  2. x86/bugs: Change L1TF mitigation string to match upstream

    bwhacks committed May 14, 2019
    Commit 72c6d2d "x86/litf: Introduce vmx status variable" upstream
    changed "Page Table Inversion" to "PTE Inversion".  That was part of
    the implementation of additional mitigations for VMX which haven't
    been applied to this branch.  Just change this string to be consistent
    and match documentation.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  3. x86/cpu/bugs: Use __initconst for 'const' init data

    Andi Kleen authored and bwhacks committed Mar 30, 2019
    commit 1de7edb upstream.
    
    Some of the recently added const tables use __initdata which causes section
    attribute conflicts.
    
    Use __initconst instead.
    
    Fixes: fa1202e ("x86/speculation: Add command line control")
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/20190330004743.29541-9-andi@firstfloor.org
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  4. x86/speculation/mds: Fix documentation typo

    jpoimboe authored and bwhacks committed May 7, 2019
    commit 95310e3 upstream.
    
    Fix a minor typo in the MDS documentation: "eanbled" -> "enabled".
    
    Reported-by: Jeff Bastian <jbastian@redhat.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  5. Documentation: Correct the possible MDS sysfs values

    tyhicks authored and bwhacks committed May 6, 2019
    commit ea01668 upstream.
    
    Adjust the last two rows in the table that display possible values when
    MDS mitigation is enabled. They both were slightly innacurate.
    
    In addition, convert the table of possible values and their descriptions
    to a list-table. The simple table format uses the top border of equals
    signs to determine cell width which resulted in the first column being
    far too wide in comparison to the second column that contained the
    majority of the text.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  6. x86/mds: Add MDSUM variant to the MDS documentation

    speck for Pawan Gupta authored and bwhacks committed May 6, 2019
    commit e672f8b upstream.
    
    Updated the documentation for a new CVE-2019-11091 Microarchitectural Data
    Sampling Uncacheable Memory (MDSUM) which is a variant of
    Microarchitectural Data Sampling (MDS). MDS is a family of side channel
    attacks on internal buffers in Intel CPUs.
    
    MDSUM is a special case of MSBDS, MFBDS and MLPDS. An uncacheable load from
    memory that takes a fault or assist can leave data in a microarchitectural
    structure that may later be observed using one of the same methods used by
    MSBDS, MFBDS or MLPDS. There are no new code changes expected for MDSUM.
    The existing mitigation for MDS applies to MDSUM as well.
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  7. x86/speculation/mds: Add 'mitigations=' support for MDS

    jpoimboe authored and bwhacks committed Apr 17, 2019
    commit 5c14068 upstream.
    
    Add MDS to the new 'mitigations=' cmdline option.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.16:
     - Drop the auto,nosmt option, which we can't support
     - Adjust filenames, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  8. x86/speculation: Support 'mitigations=' cmdline option

    jpoimboe authored and bwhacks committed Apr 12, 2019
    commit d68be4c upstream.
    
    Configure x86 runtime CPU speculation bug mitigations in accordance with
    the 'mitigations=' cmdline option.  This affects Meltdown, Spectre v2,
    Speculative Store Bypass, and L1TF.
    
    The default behavior is unchanged.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
    Reviewed-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H . Peter Anvin" <hpa@zytor.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Waiman Long <longman@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: linux-s390@vger.kernel.org
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-arch@vger.kernel.org
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Tyler Hicks <tyhicks@canonical.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Steven Price <steven.price@arm.com>
    Cc: Phil Auld <pauld@redhat.com>
    Link: https://lkml.kernel.org/r/6616d0ae169308516cfdf5216bedd169f8a8291b.1555085500.git.jpoimboe@redhat.com
    [bwh: Backported to 3.16:
     - Drop the auto,nosmt option and the l1tf mitigation selection, which we can't
       support
     - Adjust filenames, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  9. cpu/speculation: Add 'mitigations=' cmdline option

    jpoimboe authored and bwhacks committed Apr 12, 2019
    commit 98af845 upstream.
    
    Keeping track of the number of mitigations for all the CPU speculation
    bugs has become overwhelming for many users.  It's getting more and more
    complicated to decide which mitigations are needed for a given
    architecture.  Complicating matters is the fact that each arch tends to
    have its own custom way to mitigate the same vulnerability.
    
    Most users fall into a few basic categories:
    
    a) they want all mitigations off;
    
    b) they want all reasonable mitigations on, with SMT enabled even if
       it's vulnerable; or
    
    c) they want all reasonable mitigations on, with SMT disabled if
       vulnerable.
    
    Define a set of curated, arch-independent options, each of which is an
    aggregation of existing options:
    
    - mitigations=off: Disable all mitigations.
    
    - mitigations=auto: [default] Enable all the default mitigations, but
      leave SMT enabled, even if it's vulnerable.
    
    - mitigations=auto,nosmt: Enable all the default mitigations, disabling
      SMT if needed by a mitigation.
    
    Currently, these options are placeholders which don't actually do
    anything.  They will be fleshed out in upcoming patches.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
    Reviewed-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H . Peter Anvin" <hpa@zytor.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Waiman Long <longman@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: linux-s390@vger.kernel.org
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-arch@vger.kernel.org
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Tyler Hicks <tyhicks@canonical.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Steven Price <steven.price@arm.com>
    Cc: Phil Auld <pauld@redhat.com>
    Link: https://lkml.kernel.org/r/b07a8ef9b7c5055c3a4637c87d07c296d5016fe0.1555085500.git.jpoimboe@redhat.com
    [bwh: Backported to 3.16:
     - Drop the auto,nosmt option which we can't support
     - Adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  10. x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off

    konradwilk authored and bwhacks committed Apr 12, 2019
    commit e2c3c94 upstream.
    
    This code is only for CPUs which are affected by MSBDS, but are *not*
    affected by the other two MDS issues.
    
    For such CPUs, enabling the mds_idle_clear mitigation is enough to
    mitigate SMT.
    
    However if user boots with 'mds=off' and still has SMT enabled, we should
    not report that SMT is mitigated:
    
    $cat /sys//devices/system/cpu/vulnerabilities/mds
    Vulnerable; SMT mitigated
    
    But rather:
    Vulnerable; SMT vulnerable
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lkml.kernel.org/r/20190412215118.294906495@localhost.localdomain
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  11. x86/speculation/mds: Fix comment

    Boris Ostrovsky authored and bwhacks committed Apr 12, 2019
    commit cae5ec3 upstream.
    
    s/L1TF/MDS/
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  12. x86/speculation/mds: Add SMT warning message

    jpoimboe authored and bwhacks committed Apr 2, 2019
    commit 39226ef upstream.
    
    MDS is vulnerable with SMT.  Make that clear with a one-time printk
    whenever SMT first gets enabled.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  13. x86/speculation: Move arch_smt_update() call to after mitigation deci…

    jpoimboe authored and bwhacks committed Apr 2, 2019
    …sions
    
    commit 7c3658b upstream.
    
    arch_smt_update() now has a dependency on both Spectre v2 and MDS
    mitigations.  Move its initial call to after all the mitigation decisions
    have been made.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  14. Documentation: Add MDS vulnerability documentation

    Thomas Gleixner authored and bwhacks committed Feb 18, 2019
    commit 5999bbe upstream.
    
    Add the initial MDS vulnerability documentation.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Drop the index updates
     - Adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  15. Documentation: Move L1TF to separate directory

    Thomas Gleixner authored and bwhacks committed Feb 19, 2019
    commit 65fd4cb upstream.
    
    Move L!TF to a separate directory so the MDS stuff can be added at the
    side. Otherwise the all hardware vulnerabilites have their own top level
    entry. Should have done that right away.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16: we never added the documentation, so just update
     the log message]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  16. x86/speculation/mds: Add mitigation mode VMWERV

    Thomas Gleixner authored and bwhacks committed Feb 20, 2019
    commit 22dd836 upstream.
    
    In virtualized environments it can happen that the host has the microcode
    update which utilizes the VERW instruction to clear CPU buffers, but the
    hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit
    to guests.
    
    Introduce an internal mitigation mode VMWERV which enables the invocation
    of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the
    system has no updated microcode this results in a pointless execution of
    the VERW instruction wasting a few CPU cycles. If the microcode is updated,
    but not exposed to a guest then the CPU buffers will be cleared.
    
    That said: Virtual Machines Will Eventually Receive Vaccine
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  17. x86/speculation/mds: Add sysfs reporting for MDS

    Thomas Gleixner authored and bwhacks committed Feb 18, 2019
    commit 8a4b06d upstream.
    
    Add the sysfs reporting file for MDS. It exposes the vulnerability and
    mitigation state similar to the existing files for the other speculative
    hardware vulnerabilities.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Test x86_hyper instead of using hypervisor_is_type()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  18. x86/speculation/l1tf: Document l1tf in sysfs

    bwhacks committed May 11, 2019
    The vulnerabilties/l1tf attribute was added by commit 17dbca1
    "x86/speculation/l1tf: Add sysfs reporting for l1tf", which has
    already been backported to 3.16, but only documented in commit
    d90a7a0 "x86/bugs, kvm: Introduce boot-time control of L1TF
    mitigations", which has not and probbaly won't be.
    
    Add just that line of documentation for now.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  19. x86/speculation/mds: Add mitigation control for MDS

    Thomas Gleixner authored and bwhacks committed Feb 18, 2019
    commit bc12417 upstream.
    
    Now that the mitigations are in place, add a command line parameter to
    control the mitigation, a mitigation selector function and a SMT update
    mechanism.
    
    This is the minimal straight forward initial implementation which just
    provides an always on/off mode. The command line parameter is:
    
      mds=[full|off]
    
    This is consistent with the existing mitigations for other speculative
    hardware vulnerabilities.
    
    The idle invocation is dynamically updated according to the SMT state of
    the system similar to the dynamic update of the STIBP mitigation. The idle
    mitigation is limited to CPUs which are only affected by MSBDS and not any
    other variant, because the other variants cannot be mitigated on SMT
    enabled systems.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Drop " __ro_after_init"
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  20. x86/speculation/mds: Conditionally clear CPU buffers on idle entry

    Thomas Gleixner authored and bwhacks committed Feb 18, 2019
    commit 07f07f5 upstream.
    
    Add a static key which controls the invocation of the CPU buffer clear
    mechanism on idle entry. This is independent of other MDS mitigations
    because the idle entry invocation to mitigate the potential leakage due to
    store buffer repartitioning is only necessary on SMT systems.
    
    Add the actual invocations to the different halt/mwait variants which
    covers all usage sites. mwaitx is not patched as it's not available on
    Intel CPUs.
    
    The buffer clear is only invoked before entering the C-State to prevent
    that stale data from the idling CPU is spilled to the Hyper-Thread sibling
    after the Store buffer got repartitioned and all entries are available to
    the non idle sibling.
    
    When coming out of idle the store buffer is partitioned again so each
    sibling has half of it available. Now CPU which returned from idle could be
    speculatively exposed to contents of the sibling, but the buffers are
    flushed either on exit to user space or on VMENTER.
    
    When later on conditional buffer clearing is implemented on top of this,
    then there is no action required either because before returning to user
    space the context switch will set the condition flag which causes a flush
    on the return to user path.
    
    Note, that the buffer clearing on idle is only sensible on CPUs which are
    solely affected by MSBDS and not any other variant of MDS because the other
    MDS variants cannot be mitigated when SMT is enabled, so the buffer
    clearing on idle would be a window dressing exercise.
    
    This intentionally does not handle the case in the acpi/processor_idle
    driver which uses the legacy IO port interface for C-State transitions for
    two reasons:
    
     - The acpi/processor_idle driver was replaced by the intel_idle driver
       almost a decade ago. Anything Nehalem upwards supports it and defaults
       to that new driver.
    
     - The legacy IO port interface is likely to be used on older and therefore
       unaffected CPUs or on systems which do not receive microcode updates
       anymore, so there is no point in adding that.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Drop change in _mwaitx()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  21. x86/speculation/mds: Clear CPU buffers on exit to user

    Thomas Gleixner authored and bwhacks committed Feb 18, 2019
    commit 04dcbdb upstream.
    
    Add a static key which controls the invocation of the CPU buffer clear
    mechanism on exit to user space and add the call into
    prepare_exit_to_usermode() and do_nmi() right before actually returning.
    
    Add documentation which kernel to user space transition this covers and
    explain why some corner cases are not mitigated.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16: Add an assembly macro equivalent to
     mds_user_clear_cpu_buffers() and use this in the system call exit path,
     as we don't have prepare_exit_to_usermode()]
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: x86@kernel.org
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  22. x86/speculation/mds: Add mds_clear_cpu_buffers()

    Thomas Gleixner authored and bwhacks committed Feb 18, 2019
    commit 6a9e529 upstream.
    
    The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by
    clearing the affected CPU buffers. The mechanism for clearing the buffers
    uses the unused and obsolete VERW instruction in combination with a
    microcode update which triggers a CPU buffer clear when VERW is executed.
    
    Provide a inline function with the assembly magic. The argument of the VERW
    instruction must be a memory operand as documented:
    
      "MD_CLEAR enumerates that the memory-operand variant of VERW (for
       example, VERW m16) has been extended to also overwrite buffers affected
       by MDS. This buffer overwriting functionality is not guaranteed for the
       register operand variant of VERW."
    
    Documentation also recommends to use a writable data segment selector:
    
      "The buffer overwriting occurs regardless of the result of the VERW
       permission check, as well as when the selector is null or causes a
       descriptor load segment violation. However, for lowest latency we
       recommend using a selector that indicates a valid writable data
       segment."
    
    Add x86 specific documentation about MDS and the internal workings of the
    mitigation.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16: drop changes to doc index and configuration]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  23. x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests

    Andi Kleen authored and bwhacks committed Jan 19, 2019
    commit 6c4dbbd upstream.
    
    X86_FEATURE_MD_CLEAR is a new CPUID bit which is set when microcode
    provides the mechanism to invoke a flush of various exploitable CPU buffers
    by invoking the VERW instruction.
    
    Hand it through to guests so they can adjust their mitigations.
    
    This also requires corresponding qemu changes, which are available
    separately.
    
    [ tglx: Massaged changelog ]
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  24. x86/speculation/mds: Add BUG_MSBDS_ONLY

    Thomas Gleixner authored and bwhacks committed Mar 1, 2019
    commit e261f20 upstream.
    
    This bug bit is set on CPUs which are only affected by Microarchitectural
    Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.
    
    This is important because the Store Buffers are partitioned between
    Hyper-Threads so cross thread forwarding is not possible. But if a thread
    enters or exits a sleep state the store buffer is repartitioned which can
    expose data from one thread to the other. This transition can be mitigated.
    
    That means that for CPUs which are only affected by MSBDS SMT can be
    enabled, if the CPU is not affected by other SMT sensitive vulnerabilities,
    e.g. L1TF. The XEON PHI variants fall into that category. Also the
    Silvermont/Airmont ATOMs, but for them it's not really relevant as they do
    not support SMT, but mark them for completeness sake.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Assign the next available bug flag
     - Adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  25. x86/speculation/mds: Add basic bug infrastructure for MDS

    Andi Kleen authored and bwhacks committed Jan 19, 2019
    commit ed5194c upstream.
    
    Microarchitectural Data Sampling (MDS), is a class of side channel attacks
    on internal buffers in Intel CPUs. The variants are:
    
     - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)
     - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)
     - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)
    
    MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
    dependent load (store-to-load forwarding) as an optimization. The forward
    can also happen to a faulting or assisting load operation for a different
    memory address, which can be exploited under certain conditions. Store
    buffers are partitioned between Hyper-Threads so cross thread forwarding is
    not possible. But if a thread enters or exits a sleep state the store
    buffer is repartitioned which can expose data from one thread to the other.
    
    MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage
    L1 miss situations and to hold data which is returned or sent in response
    to a memory or I/O operation. Fill buffers can forward data to a load
    operation and also write data to the cache. When the fill buffer is
    deallocated it can retain the stale data of the preceding operations which
    can then be forwarded to a faulting or assisting load operation, which can
    be exploited under certain conditions. Fill buffers are shared between
    Hyper-Threads so cross thread leakage is possible.
    
    MLDPS leaks Load Port Data. Load ports are used to perform load operations
    from memory or I/O. The received data is then forwarded to the register
    file or a subsequent operation. In some implementations the Load Port can
    contain stale data from a previous operation which can be forwarded to
    faulting or assisting loads under certain conditions, which again can be
    exploited eventually. Load ports are shared between Hyper-Threads so cross
    thread leakage is possible.
    
    All variants have the same mitigation for single CPU thread case (SMT off),
    so the kernel can treat them as one MDS issue.
    
    Add the basic infrastructure to detect if the current CPU is affected by
    MDS.
    
    [ tglx: Rewrote changelog ]
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Use CPU feature word 10 and next available bug flag
     - Adjust filename, context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  26. x86/speculation: Consolidate CPU whitelists

    Thomas Gleixner authored and bwhacks committed Feb 27, 2019
    commit 36ad351 upstream.
    
    The CPU vulnerability whitelists have some overlap and there are more
    whitelists coming along.
    
    Use the driver_data field in the x86_cpu_id struct to denote the
    whitelisted vulnerabilities and combine all whitelists into one.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  27. x86/msr-index: Cleanup bit defines

    Thomas Gleixner authored and bwhacks committed Feb 21, 2019
    commit d8eabc3 upstream.
    
    Greg pointed out that speculation related bit defines are using (1 << N)
    format instead of BIT(N). Aside of that (1 << N) is wrong as it should use
    1UL at least.
    
    Clean it up.
    
    [ Josh Poimboeuf: Fix tools build ]
    
    Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Tested-by: Jon Masters <jcm@redhat.com>
    [bwh: Backported to 3.16:
     - Since <asm/msr-index.h> is a UAPI header here, open-code BIT() and drop
       changes under tools/
     - Drop changes to flush MSRs which we haven't defined]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  28. kvm: x86: Report STIBP on GET_SUPPORTED_CPUID

    ehabkost authored and bwhacks committed Dec 5, 2018
    commit d7b09c8 upstream.
    
    Months ago, we have added code to allow direct access to MSR_IA32_SPEC_CTRL
    to the guest, which makes STIBP available to guests.  This was implemented
    by commits d28b387 ("KVM/VMX: Allow direct access to
    MSR_IA32_SPEC_CTRL") and b2ac58f ("KVM/SVM: Allow direct access to
    MSR_IA32_SPEC_CTRL").
    
    However, we never updated GET_SUPPORTED_CPUID to let userspace know that
    STIBP can be enabled in CPUID.  Fix that by updating
    kvm_cpuid_8000_0008_ebx_x86_features and kvm_cpuid_7_0_edx_x86_features.
    
    Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  29. x86/speculation: Provide IBPB always command line options

    Thomas Gleixner authored and bwhacks committed Nov 25, 2018
    commit 55a9740 upstream.
    
    Provide the possibility to enable IBPB always in combination with 'prctl'
    and 'seccomp'.
    
    Add the extra command line options and rework the IBPB selection to
    evaluate the command instead of the mode selected by the STIPB switch case.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Link: https://lkml.kernel.org/r/20181125185006.144047038@linutronix.de
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  30. x86/speculation: Add seccomp Spectre v2 user space protection mode

    Thomas Gleixner authored and bwhacks committed Nov 25, 2018
    commit 6b3e64c upstream.
    
    If 'prctl' mode of user space protection from spectre v2 is selected
    on the kernel command-line, STIBP and IBPB are applied on tasks which
    restrict their indirect branch speculation via prctl.
    
    SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
    makes sense to prevent spectre v2 user space to user space attacks as
    well.
    
    The Intel mitigation guide documents how STIPB works:
    
       Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
       prevents the predicted targets of indirect branches on any logical
       processor of that core from being controlled by software that executes
       (or executed previously) on another logical processor of the same core.
    
    Ergo setting STIBP protects the task itself from being attacked from a task
    running on a different hyper-thread and protects the tasks running on
    different hyper-threads from being attacked.
    
    While the document suggests that the branch predictors are shielded between
    the logical processors, the observed performance regressions suggest that
    STIBP simply disables the branch predictor more or less completely. Of
    course the document wording is vague, but the fact that there is also no
    requirement for issuing IBPB when STIBP is used points clearly in that
    direction. The kernel still issues IBPB even when STIBP is used until Intel
    clarifies the whole mechanism.
    
    IBPB is issued when the task switches out, so malicious sandbox code cannot
    mistrain the branch predictor for the next user space task on the same
    logical processor.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Link: https://lkml.kernel.org/r/20181125185006.051663132@linutronix.de
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  31. x86/speculation: Enable prctl mode for spectre_v2_user

    Thomas Gleixner authored and bwhacks committed Nov 25, 2018
    commit 7cc765a upstream.
    
    Now that all prerequisites are in place:
    
     - Add the prctl command line option
    
     - Default the 'auto' mode to 'prctl'
    
     - When SMT state changes, update the static key which controls the
       conditional STIBP evaluation on context switch.
    
     - At init update the static key which controls the conditional IBPB
       evaluation on context switch.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Link: https://lkml.kernel.org/r/20181125185005.958421388@linutronix.de
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  32. x86/speculation: Add prctl() control for indirect branch speculation

    Thomas Gleixner authored and bwhacks committed Nov 25, 2018
    commit 9137bb2 upstream.
    
    Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
    PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
    indirect branch speculation via STIBP and IBPB.
    
    Invocations:
     Check indirect branch speculation status with
     - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
    
     Enable indirect branch speculation with
     - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
    
     Disable indirect branch speculation with
     - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
    
     Force disable indirect branch speculation with
     - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
    
    See Documentation/userspace-api/spec_ctrl.rst.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
    [bwh: Backported to 3.16:
     - Drop changes in tools/include/uapi/linux/prctl.h
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  33. x86/speculation: Prevent stale SPEC_CTRL msr content

    Thomas Gleixner authored and bwhacks committed Nov 28, 2018
    commit 6d991ba upstream.
    
    The seccomp speculation control operates on all tasks of a process, but
    only the current task of a process can update the MSR immediately. For the
    other threads the update is deferred to the next context switch.
    
    This creates the following situation with Process A and B:
    
    Process A task 2 and Process B task 1 are pinned on CPU1. Process A task 2
    does not have the speculation control TIF bit set. Process B task 1 has the
    speculation control TIF bit set.
    
    CPU0					CPU1
    					MSR bit is set
    					ProcB.T1 schedules out
    					ProcA.T2 schedules in
    					MSR bit is cleared
    ProcA.T1
      seccomp_update()
      set TIF bit on ProcA.T2
    					ProcB.T1 schedules in
    					MSR is not updated  <-- FAIL
    
    This happens because the context switch code tries to avoid the MSR update
    if the speculation control TIF bits of the incoming and the outgoing task
    are the same. In the worst case ProcB.T1 and ProcA.T2 are the only tasks
    scheduling back and forth on CPU1, which keeps the MSR stale forever.
    
    In theory this could be remedied by IPIs, but chasing the remote task which
    could be migrated is complex and full of races.
    
    The straight forward solution is to avoid the asychronous update of the TIF
    bit and defer it to the next context switch. The speculation control state
    is stored in task_struct::atomic_flags by the prctl and seccomp updates
    already.
    
    Add a new TIF_SPEC_FORCE_UPDATE bit and set this after updating the
    atomic_flags. Check the bit on context switch and force a synchronous
    update of the speculation control if set. Use the same mechanism for
    updating the current task.
    
    Reported-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1811272247140.1875@nanos.tec.linutronix.de
    [bwh: Backported to 3.16:
     - Assign the first available thread_info flag
     - Exclude _TIF_SPEC_FORCE_UPDATE from _TIF_WORK_MASK and _TIF_ALLWORK_MASK]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Older
You can’t perform that action at this time.