commit 2af67d29b6fec54b86bcdb3e0a616640eeea5302
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 14 19:18:47 2019 +0200

    Linux 4.14.119

commit 562ebbecef1e0b0b298c8d67dcad7d386905dedf
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Tue May 7 15:05:22 2019 -0500

    x86/speculation/mds: Fix documentation typo
    
    commit 95310e348a321b45fb746c176961d4da72344282 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f72365861da80c840ae9343f3ab11c5ae19e423
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Mon May 6 23:52:58 2019 +0000

    Documentation: Correct the possible MDS sysfs values
    
    commit ea01668f9f43021b28b3f4d5ffad50106a1e1301 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12bafbc2e34f2aeadb762b9e72103a84a66f4b8f
Author: speck for Pawan Gupta <speck@linutronix.de>
Date:   Mon May 6 12:23:50 2019 -0700

    x86/mds: Add MDSUM variant to the MDS documentation
    
    commit e672f8bf71c66253197e503f75c771dd28ada4a0 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9411900c4223cbe4926dd2954e762de1816fcec
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Wed Apr 17 16:39:02 2019 -0500

    x86/speculation/mds: Add 'mitigations=' support for MDS
    
    commit 5c14068f87d04adc73ba3f41c2a303d3c3d1fa12 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91788fcb21d008b1b7ac6beae20522725fa78239
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri Apr 12 15:39:31 2019 -0500

    s390/speculation: Support 'mitigations=' cmdline option
    
    commit 0336e04a6520bdaefdb0769d2a70084fa52e81ed upstream
    
    Configure s390 runtime CPU speculation bug mitigations in accordance
    with the 'mitigations=' cmdline option.  This affects Spectre v1 and
    Spectre v2.
    
    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/e4a161805458a5ec88812aac0307ae3908a030fc.1555085500.git.jpoimboe@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c2eb44188330f72c9e7efad8a64043e08f0ccef
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri Apr 12 15:39:30 2019 -0500

    powerpc/speculation: Support 'mitigations=' cmdline option
    
    commit 782e69efb3dfed6e8360bc612e8c7827a901a8f9 upstream
    
    Configure powerpc CPU runtime speculation bug mitigations in accordance
    with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
    v1, Spectre v2, and Speculative Store Bypass.
    
    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/245a606e1a42a558a310220312d9b6adb9159df6.1555085500.git.jpoimboe@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 275fdd26311d2ba0fffcb02b3d5b784e4d2b5a10
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri Apr 12 15:39:29 2019 -0500

    x86/speculation: Support 'mitigations=' cmdline option
    
    commit d68be4c4d31295ff6ae34a8ddfaa4c1a8ff42812 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
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed1dfe838f313793e922f6a81f7b8b89b0de3c74
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri Apr 12 15:39:28 2019 -0500

    cpu/speculation: Add 'mitigations=' cmdline option
    
    commit 98af8452945c55652de68536afdde3b520fec429 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
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b86151879fa5ee74ebcd76ed54ad59bc27d79b8b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Apr 12 17:50:58 2019 -0400

    x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off
    
    commit e2c3c94788b08891dcf3dbe608f9880523ecd71b 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56932cc808295621afaea9331f5c6be79af655c8
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Fri Apr 12 17:50:57 2019 -0400

    x86/speculation/mds: Fix comment
    
    commit cae5ec342645746d617dd420d206e1588d47768a 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98ebc07125b74bfe6cbfd0e4a982623c1004a237
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Tue Apr 2 10:00:51 2019 -0500

    x86/speculation/mds: Add SMT warning message
    
    commit 39226ef02bfb43248b7db12a4fdccb39d95318e3 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fff6165579440b1fa4a81d19d410c090e4154dd
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Tue Apr 2 10:00:14 2019 -0500

    x86/speculation: Move arch_smt_update() call to after mitigation decisions
    
    commit 7c3658b20194a5b3209a143f63bc9c643c6a3ae2 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19ae10e543855f24ff873212b4a10e1e7b3e99ee
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Tue Apr 2 09:59:33 2019 -0500

    x86/speculation/mds: Add mds=full,nosmt cmdline option
    
    commit d71eb0ce109a124b0fa714832823b9452f2762cf upstream
    
    Add the mds=full,nosmt cmdline option.  This is like mds=full, but with
    SMT disabled if the CPU is vulnerable.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1f93c538746dd578028efbe35f59dd05945ab51
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Feb 19 00:02:31 2019 +0100

    Documentation: Add MDS vulnerability documentation
    
    commit 5999bbe7a6ea3c62029532ec84dc06003a1fa258 upstream
    
    Add the initial MDS vulnerability documentation.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Jon Masters <jcm@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb73e805deb2b96a07e331a3cf24c02def7347f7
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Feb 19 11:10:49 2019 +0100

    Documentation: Move L1TF to separate directory
    
    commit 65fd4cb65b2dad97feb8330b6690445910b56d6a 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1600abb55986daae2de024de5007362a5295d893
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 20 09:40:40 2019 +0100

    x86/speculation/mds: Add mitigation mode VMWERV
    
    commit 22dd8365088b6403630b82423cf906491859b65e 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 644386d19f4beb353b73b664a11c4821007ee125
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Feb 18 22:51:43 2019 +0100

    x86/speculation/mds: Add sysfs reporting for MDS
    
    commit 8a4b06d391b0a42a373808979b5028f5c84d9c6a 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e87b33f416fcdeaa29be85e1e4a1c43a0b66f1a
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Feb 18 22:04:08 2019 +0100

    x86/speculation/mds: Add mitigation control for MDS
    
    commit bc1241700acd82ec69fde98c5763ce51086269f8 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d72f9922d7d14c31fa690ea05fec7293fd9b0fd6
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Feb 18 23:04:01 2019 +0100

    x86/speculation/mds: Conditionally clear CPU buffers on idle entry
    
    commit 07f07f55a29cb705e221eda7894dd67ab81ef343 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 787311ce7faee98627d41aa254114b55ddf8276c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 27 12:48:14 2019 +0100

    x86/kvm/vmx: Add MDS protection when L1D Flush is not active
    
    commit 650b68a0622f933444a6d66936abb3103029413b upstream
    
    CPUs which are affected by L1TF and MDS mitigate MDS with the L1D Flush on
    VMENTER when updated microcode is installed.
    
    If a CPU is not affected by L1TF or if the L1D Flush is not in use, then
    MDS mitigation needs to be invoked explicitly.
    
    For these cases, follow the host mitigation state and invoke the MDS
    mitigation before VMENTER.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfa08d23f92e839b9de8e85f3643b8516d49f861
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Feb 18 23:42:51 2019 +0100

    x86/speculation/mds: Clear CPU buffers on exit to user
    
    commit 04dcbdb8057827b043b3c71aa397c4c63e67d086 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ce6c4a19413b1219dc26ba5564c073e971f97f4
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Feb 18 23:13:06 2019 +0100

    x86/speculation/mds: Add mds_clear_cpu_buffers()
    
    commit 6a9e529272517755904b7afa639f6db59ddb793e 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a3e50c93ad920f78285a1d93cc1202e13c739ed
Author: Andi Kleen <ak@linux.intel.com>
Date:   Fri Jan 18 16:50:23 2019 -0800

    x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
    
    commit 6c4dbbd14730c43f4ed808a9c42ca41625925c22 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a805a7f0ea26ae1f2f203c67d55bd9392038697
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Mar 1 20:21:08 2019 +0100

    x86/speculation/mds: Add BUG_MSBDS_ONLY
    
    commit e261f209c3666e842fd645a1e31f001c3a26def9 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f619a159ac06718810e8548fabbd53bcae61f204
Author: Andi Kleen <ak@linux.intel.com>
Date:   Fri Jan 18 16:50:16 2019 -0800

    x86/speculation/mds: Add basic bug infrastructure for MDS
    
    commit ed5194c2732c8084af9fd159c146ea92bf137128 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1553938d28919f36d2657fdb9a6ada5c5405d950
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 27 10:10:23 2019 +0100

    x86/speculation: Consolidate CPU whitelists
    
    commit 36ad35131adacc29b328b9c8b6277a8bf0d6fd5d 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3de6f43b23c7c1b08e0acb72e2fba76ee98bc612
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Feb 21 12:36:50 2019 +0100

    x86/msr-index: Cleanup bit defines
    
    commit d8eabc37310a92df40d07c5a8afc53cebf996716 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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29499dae76101591b3c5f6050954a702b298a93f
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Jun 19 13:53:08 2018 +0100

    locking/atomics, asm-generic: Move some macros from <linux/bitops.h> to a new <linux/bits.h> file
    
    commit 8bd9cb51daac89337295b6f037b0486911e1b408 upstream
    
    In preparation for implementing the asm-generic atomic bitops in terms
    of atomic_long_*(), we need to prevent <asm/atomic.h> implementations from
    pulling in <linux/bitops.h>. A common reason for this include is for the
    BITS_PER_BYTE definition, so move this and some other BIT() and masking
    macros into a new header file, <linux/bits.h>.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: yamada.masahiro@socionext.com
    Link: https://lore.kernel.org/lkml/1529412794-17720-4-git-send-email-will.deacon@arm.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba8451a88c05db11a5d302607852f920bcdc47f9
Author: Eduardo Habkost <ehabkost@redhat.com>
Date:   Wed Dec 5 17:19:56 2018 -0200

    kvm: x86: Report STIBP on GET_SUPPORTED_CPUID
    
    commit d7b09c827a6cf291f66637a36f46928dd1423184 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 d28b387fb74d ("KVM/VMX: Allow direct access to
    MSR_IA32_SPEC_CTRL") and b2ac58f90540 ("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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb8921e584dec56e320c49d6248480f11be7c3a3
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Aug 7 10:17:27 2018 -0700

    x86/cpu: Sanitize FAM6_ATOM naming
    
    commit f2c4db1bd80720cd8cb2a5aa220d9bc9f374f04e upstream
    
    Going primarily by:
    
      https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors
    
    with additional information gleaned from other related pages; notably:
    
     - Bonnell shrink was called Saltwell
     - Moorefield is the Merriefield refresh which makes it Airmont
    
    The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
    
      for i in `git grep -l FAM6_ATOM` ; do
            sed -i  -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g'             \
                    -e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/'          \
                    -e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g'         \
                    -e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g'   \
                    -e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g'           \
                    -e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g'       \
                    -e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g'     \
                    -e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g'    \
                    -e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g'       \
                    -e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g'         \
                    -e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i}
      done
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Cc: dave.hansen@linux.intel.com
    Cc: len.brown@intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc3168560ec1f8e1b98808796a3d624e2f86c4b4
Author: Salvatore Bonaccorso <carnil@debian.org>
Date:   Wed Aug 15 07:46:04 2018 +0200

    Documentation/l1tf: Fix small spelling typo
    
    commit 60ca05c3b44566b70d64fbb8e87a6e0c67725468 upstream
    
    Fix small typo (wiil -> will) in the "3.4. Nested virtual machines"
    section.
    
    Fixes: 5b76a3cff011 ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry")
    Cc: linux-kernel@vger.kernel.org
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: linux-doc@vger.kernel.org
    Cc: trivial@kernel.org
    
    Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80ceda7ba9cbcd01994fb5d5fdb188113f664daa
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Tue May 22 11:05:39 2018 +0200

    x86/speculation: Simplify the CPU bug detection logic
    
    commit 8ecc4979b1bd9c94168e6fc92960033b7a951336 upstream
    
    Only CPUs which speculate can speculate. Therefore, it seems prudent
    to test for cpu_no_speculation first and only then determine whether
    a specific speculating CPU is susceptible to store bypass speculation.
    This is underlined by all CPUs currently listed in cpu_no_speculation
    were present in cpu_no_spec_store_bypass as well.
    
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: bp@suse.de
    Cc: konrad.wilk@oracle.com
    Link: https://lkml.kernel.org/r/20180522090539.GA24668@light.dominikbrodowski.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>