Commit a3c12cf3 authored by Takahiro Itazuri's avatar Takahiro Itazuri Committed by Jonathan Corbet
Browse files

docs/hw-vuln: Update desc of best effort mode 



Moves the description of the best effort mitigation mode to the table of
the possible values in the mds and tsx_async_abort docs, and adds the
same one to the mmio_stale_data doc.

Signed-off-by: default avatarTakahiro Itazuri <itazur@amazon.com>
Reviewed-by: default avatarPawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20230901082959.28310-1-itazur@amazon.com
parent c9ad95ad

Documentation/admin-guide/hw-vuln/mds.rst

+13 −21
Original line number Diff line number Diff line
@@ -102,9 +102,19 @@ The possible values in this file are: 
     * - '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 processor is vulnerable but microcode is not updated. The

         mitigation is enabled on a best effort basis.



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

         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.

     * - 'Mitigation: Clear CPU buffers'

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

         enabled.
@@ -119,24 +129,6 @@ to the above information: 
    '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

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

Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst

+12 −1
Original line number Diff line number Diff line
@@ -225,8 +225,19 @@ The possible values in this file are: 
     * - '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

       - The processor is vulnerable but microcode is not updated. The

         mitigation is enabled on a best effort basis.



         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.

     * - 'Mitigation: Clear CPU buffers'

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

         enabled.

Documentation/admin-guide/hw-vuln/tsx_async_abort.rst

+13 −20
Original line number Diff line number Diff line
@@ -98,7 +98,19 @@ The possible values in this file are: 
   * - 'Vulnerable'

     - The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied.

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

     - The system tries to clear the buffers but the microcode might not support the operation.

     - The processor is vulnerable but microcode is not updated. The

       mitigation is enabled on a best effort basis.



       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.

   * - 'Mitigation: Clear CPU buffers'

     - The microcode has been updated to clear the buffers. TSX is still enabled.

   * - 'Mitigation: TSX disabled'
@@ -106,25 +118,6 @@ The possible values in this file are: 
   * - 'Not affected'

     - The CPU is not affected by this issue.



.. _ucode_needed:



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 tsx_async_abort sysfs file reflects this situation

accordingly.





Mitigation mechanism

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