Merge 4.4.180 into android-4.4

		/sys/devices/system/cpu/vulnerabilities/spectre_v1

		/sys/devices/system/cpu/vulnerabilities/spectre_v2

		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass

		/sys/devices/system/cpu/vulnerabilities/l1tf

		/sys/devices/system/cpu/vulnerabilities/mds

Date:		January 2018

Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>

Description:	Information about CPU vulnerabilities

MDS - Microarchitectural Data Sampling

======================================

Microarchitectural Data Sampling is a hardware vulnerability which allows

unprivileged speculative access to data which is available in various CPU

internal buffers.

Affected processors

-------------------

This vulnerability affects a wide range of Intel processors. The

vulnerability is not present on:

   - Processors from AMD, Centaur and other non Intel vendors

   - Older processor models, where the CPU family is < 6

   - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)

   - Intel processors which have the ARCH_CAP_MDS_NO bit set in the

     IA32_ARCH_CAPABILITIES MSR.

Whether a processor is affected or not can be read out from the MDS

vulnerability file in sysfs. See :ref:`mds_sys_info`.

Not all processors are affected by all variants of MDS, but the mitigation

is identical for all of them so the kernel treats them as a single

vulnerability.

Related CVEs

------------

The following CVE entries are related to the MDS vulnerability:

   ==============  =====  ===================================================

   CVE-2018-12126  MSBDS  Microarchitectural Store Buffer Data Sampling

   CVE-2018-12130  MFBDS  Microarchitectural Fill Buffer Data Sampling

   CVE-2018-12127  MLPDS  Microarchitectural Load Port Data Sampling

   CVE-2019-11091  MDSUM  Microarchitectural Data Sampling Uncacheable Memory

   ==============  =====  ===================================================

Problem

-------

When performing store, load, L1 refill operations, processors write data

into temporary microarchitectural structures (buffers). The data in the

buffer can be forwarded to load operations as an optimization.

Under certain conditions, usually a fault/assist caused by a load

operation, data unrelated to the load memory address can be speculatively

forwarded from the buffers. Because the load operation causes a fault or

assist and its result will be discarded, the forwarded data will not cause

incorrect program execution or state changes. But a malicious operation

may be able to forward this speculative data to a disclosure gadget which

allows in turn to infer the value via a cache side channel attack.

Because the buffers are potentially shared between Hyper-Threads cross

Hyper-Thread attacks are possible.

Deeper technical information is available in the MDS specific x86

architecture section: :ref:`Documentation/x86/mds.rst <mds>`.

Attack scenarios

----------------

Attacks against the MDS vulnerabilities can be mounted from malicious non

priviledged user space applications running on hosts or guest. Malicious

guest OSes can obviously mount attacks as well.

Contrary to other speculation based vulnerabilities the MDS vulnerability

does not allow the attacker to control the memory target address. As a

consequence the attacks are purely sampling based, but as demonstrated with

the TLBleed attack samples can be postprocessed successfully.

Web-Browsers

^^^^^^^^^^^^

  It's unclear whether attacks through Web-Browsers are possible at

  all. The exploitation through Java-Script is considered very unlikely,

  but other widely used web technologies like Webassembly could possibly be

  abused.

.. _mds_sys_info:

MDS system information

-----------------------

The Linux kernel provides a sysfs interface to enumerate the current MDS

status of the system: whether the system is vulnerable, and which

mitigations are active. The relevant sysfs file is:

/sys/devices/system/cpu/vulnerabilities/mds

The possible values in this file are:

  .. list-table::

     * - 'Not affected'

       - The processor is not vulnerable

     * - 'Vulnerable'

       - The processor is vulnerable, but no mitigation enabled

     * - 'Vulnerable: Clear CPU buffers attempted, no microcode'

       - The processor is vulnerable but microcode is not updated.

         The mitigation is enabled on a best effort basis. See :ref:`vmwerv`

     * - 'Mitigation: Clear CPU buffers'

       - The processor is vulnerable and the CPU buffer clearing mitigation is

         enabled.

If the processor is vulnerable then the following information is appended

to the above information:

    ========================  ============================================

    'SMT vulnerable'          SMT is enabled

    'SMT mitigated'           SMT is enabled and mitigated

    'SMT disabled'            SMT is disabled

    'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown

    ========================  ============================================

.. _vmwerv:

Best effort mitigation mode

^^^^^^^^^^^^^^^^^^^^^^^^^^^

  If the processor is vulnerable, but the availability of the microcode based

  mitigation mechanism is not advertised via CPUID the kernel selects a best

  effort mitigation mode.  This mode invokes the mitigation instructions

  without a guarantee that they clear the CPU buffers.

  This is done to address virtualization scenarios where the host has the

  microcode update applied, but the hypervisor is not yet updated to expose

  the CPUID to the guest. If the host has updated microcode the protection

  takes effect otherwise a few cpu cycles are wasted pointlessly.

  The state in the mds sysfs file reflects this situation accordingly.

Mitigation mechanism

-------------------------

The kernel detects the affected CPUs and the presence of the microcode

which is required.

If a CPU is affected and the microcode is available, then the kernel

enables the mitigation by default. The mitigation can be controlled at boot

time via a kernel command line option. See

:ref:`mds_mitigation_control_command_line`.

.. _cpu_buffer_clear:

CPU buffer clearing

^^^^^^^^^^^^^^^^^^^

  The mitigation for MDS clears the affected CPU buffers on return to user

  space and when entering a guest.

  If SMT is enabled it also clears the buffers on idle entry when the CPU

  is only affected by MSBDS and not any other MDS variant, because the

  other variants cannot be protected against cross Hyper-Thread attacks.

  For CPUs which are only affected by MSBDS the user space, guest and idle

  transition mitigations are sufficient and SMT is not affected.

.. _virt_mechanism:

Virtualization mitigation

^^^^^^^^^^^^^^^^^^^^^^^^^

  The protection for host to guest transition depends on the L1TF

  vulnerability of the CPU:

  - CPU is affected by L1TF:

    If the L1D flush mitigation is enabled and up to date microcode is

    available, the L1D flush mitigation is automatically protecting the

    guest transition.

    If the L1D flush mitigation is disabled then the MDS mitigation is

    invoked explicit when the host MDS mitigation is enabled.

    For details on L1TF and virtualization see:

    :ref:`Documentation/hw-vuln//l1tf.rst <mitigation_control_kvm>`.

  - CPU is not affected by L1TF:

    CPU buffers are flushed before entering the guest when the host MDS

    mitigation is enabled.

  The resulting MDS protection matrix for the host to guest transition:

  ============ ===== ============= ============ =================

   L1TF         MDS   VMX-L1FLUSH   Host MDS     MDS-State

   Don't care   No    Don't care    N/A          Not affected

   Yes          Yes   Disabled      Off          Vulnerable

   Yes          Yes   Disabled      Full         Mitigated

   Yes          Yes   Enabled       Don't care   Mitigated

   No           Yes   N/A           Off          Vulnerable

   No           Yes   N/A           Full         Mitigated

  ============ ===== ============= ============ =================

  This only covers the host to guest transition, i.e. prevents leakage from

  host to guest, but does not protect the guest internally. Guests need to

  have their own protections.

.. _xeon_phi:

XEON PHI specific considerations

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  The XEON PHI processor family is affected by MSBDS which can be exploited

  cross Hyper-Threads when entering idle states. Some XEON PHI variants allow

  to use MWAIT in user space (Ring 3) which opens an potential attack vector

  for malicious user space. The exposure can be disabled on the kernel

  command line with the 'ring3mwait=disable' command line option.

  XEON PHI is not affected by the other MDS variants and MSBDS is mitigated

  before the CPU enters a idle state. As XEON PHI is not affected by L1TF

  either disabling SMT is not required for full protection.

.. _mds_smt_control:

SMT control

^^^^^^^^^^^

  All MDS variants except MSBDS can be attacked cross Hyper-Threads. That

  means on CPUs which are affected by MFBDS or MLPDS it is necessary to

  disable SMT for full protection. These are most of the affected CPUs; the

  exception is XEON PHI, see :ref:`xeon_phi`.

  Disabling SMT can have a significant performance impact, but the impact

  depends on the type of workloads.

  See the relevant chapter in the L1TF mitigation documentation for details:

  :ref:`Documentation/hw-vuln/l1tf.rst <smt_control>`.

.. _mds_mitigation_control_command_line:

Mitigation control on the kernel command line

---------------------------------------------

The kernel command line allows to control the MDS mitigations at boot

time with the option "mds=". The valid arguments for this option are:

  ============  =============================================================

  full		If the CPU is vulnerable, enable all available mitigations

		for the MDS vulnerability, CPU buffer clearing on exit to

		userspace and when entering a VM. Idle transitions are

		protected as well if SMT is enabled.

		It does not automatically disable SMT.

  off		Disables MDS mitigations completely.

  ============  =============================================================

Not specifying this option is equivalent to "mds=full".

Mitigation selection guide

--------------------------

1. Trusted userspace

^^^^^^^^^^^^^^^^^^^^

   If all userspace applications are from a trusted source and do not

   execute untrusted code which is supplied externally, then the mitigation

   can be disabled.

2. Virtualization with trusted guests

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   The same considerations as above versus trusted user space apply.

3. Virtualization with untrusted guests

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   The protection depends on the state of the L1TF mitigations.

   See :ref:`virt_mechanism`.

   If the MDS mitigation is enabled and SMT is disabled, guest to host and

   guest to guest attacks are prevented.

.. _mds_default_mitigations:

Default mitigations

-------------------

  The kernel default mitigations for vulnerable processors are:

  - Enable CPU buffer clearing

  The kernel does not by default enforce the disabling of SMT, which leaves

  SMT systems vulnerable when running untrusted code. The same rationale as

  for L1TF applies.

  See :ref:`Documentation/hw-vuln//l1tf.rst <default_mitigations>`.

			Format: <first>,<last>

			Specifies range of consoles to be captured by the MDA.

	mds=		[X86,INTEL]

			Control mitigation for the Micro-architectural Data

			Sampling (MDS) vulnerability.

			Certain CPUs are vulnerable to an exploit against CPU

			internal buffers which can forward information to a

			disclosure gadget under certain conditions.

			In vulnerable processors, the speculatively

			forwarded data can be used in a cache side channel

			attack, to access data to which the attacker does

			not have direct access.

			This parameter controls the MDS mitigation. The

			options are:

			full    - Enable MDS mitigation on vulnerable CPUs

			off     - Unconditionally disable MDS mitigation

			Not specifying this option is equivalent to

			mds=full.

			For details see: Documentation/hw-vuln/mds.rst

	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory

			Amount of memory to be used when the kernel is not able

			to see the whole system memory or for test.

			in the "bleeding edge" mini2440 support kernel at

			http://repo.or.cz/w/linux-2.6/mini2440.git

	mitigations=

			[X86] Control optional mitigations for CPU

			vulnerabilities.  This is a set of curated,

			arch-independent options, each of which is an

			aggregation of existing arch-specific options.

			off

				Disable all optional CPU mitigations.  This

				improves system performance, but it may also

				expose users to several CPU vulnerabilities.

				Equivalent to: nopti [X86]

					       nospectre_v2 [X86]

					       spectre_v2_user=off [X86]

					       spec_store_bypass_disable=off [X86]

					       mds=off [X86]

			auto (default)

				Mitigate all CPU vulnerabilities, but leave SMT

				enabled, even if it's vulnerable.  This is for

				users who don't want to be surprised by SMT

				getting disabled across kernel upgrades, or who

				have other ways of avoiding SMT-based attacks.

				Equivalent to: (default behavior)

	mminit_loglevel=

			[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this

			parameter allows control of the logging verbosity for

	nohugeiomap	[KNL,x86] Disable kernel huge I/O mappings.

	nospectre_v2	[X86] Disable all mitigations for the Spectre variant 2

	nospectre_v1	[PPC] Disable mitigations for Spectre Variant 1 (bounds

			check bypass). With this option data leaks are possible

			in the system.

	nospectre_v2	[X86,PPC_FSL_BOOK3E] Disable all mitigations for the Spectre variant 2

			(indirect branch prediction) vulnerability. System may

			allow data leaks with this option, which is equivalent

			to spectre_v2=off.

	spectre_v2=	[X86] Control mitigation of Spectre variant 2

			(indirect branch speculation) vulnerability.

			The default operation protects the kernel from

			user space attacks.

			on   - unconditionally enable

			off  - unconditionally disable

			on   - unconditionally enable, implies

			       spectre_v2_user=on

			off  - unconditionally disable, implies

			       spectre_v2_user=off

			auto - kernel detects whether your CPU model is

			       vulnerable

			CONFIG_RETPOLINE configuration option, and the

			compiler with which the kernel was built.

			Selecting 'on' will also enable the mitigation

			against user space to user space task attacks.

			Selecting 'off' will disable both the kernel and

			the user space protections.

			Specific mitigations can also be selected manually:

			retpoline	  - replace indirect branches

			Not specifying this option is equivalent to

			spectre_v2=auto.

	spectre_v2_user=

			[X86] Control mitigation of Spectre variant 2

		        (indirect branch speculation) vulnerability between

		        user space tasks

			on	- Unconditionally enable mitigations. Is

				  enforced by spectre_v2=on

			off     - Unconditionally disable mitigations. Is

				  enforced by spectre_v2=off

			prctl   - Indirect branch speculation is enabled,

				  but mitigation can be enabled via prctl

				  per thread.  The mitigation control state

				  is inherited on fork.

			prctl,ibpb

				- Like "prctl" above, but only STIBP is

				  controlled per thread. IBPB is issued

				  always when switching between different user

				  space processes.

			seccomp

				- Same as "prctl" above, but all seccomp

				  threads will enable the mitigation unless

				  they explicitly opt out.

			seccomp,ibpb

				- Like "seccomp" above, but only STIBP is

				  controlled per thread. IBPB is issued

				  always when switching between different

				  user space processes.

			auto    - Kernel selects the mitigation depending on

				  the available CPU features and vulnerability.

			Default mitigation:

			If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"

			Not specifying this option is equivalent to

			spectre_v2_user=auto.

	spec_store_bypass_disable=

			[HW] Control Speculative Store Bypass (SSB) Disable mitigation

			(Speculative Store Bypass vulnerability)

	minimum RTT when it is moved to a longer path (e.g., due to traffic

	engineering). A longer window makes the filter more resistant to RTT

	inflations such as transient congestion. The unit is seconds.

	Possible values: 0 - 86400 (1 day)

	Default: 300

tcp_moderate_rcvbuf - BOOLEAN

   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_ENABLE, 0, 0);

   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_DISABLE, 0, 0);

   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_FORCE_DISABLE, 0, 0);

- PR_SPEC_INDIR_BRANCH: Indirect Branch Speculation in User Processes

                        (Mitigate Spectre V2 style attacks against user processes)

  Invocations:

   * prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);

   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);

   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);

   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);