Commit 3f1a1526 authored by Tony Luck's avatar Tony Luck Committed by Stefan Bader

Documentation/l1tf: Fix typos

Fix spelling and other typos
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>

CVE-2018-3620
CVE-2018-3646

[smb: Location changed to Documentation/security/l1tf.txt]
Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
parent bbd637c6
...@@ -17,7 +17,7 @@ vulnerability is not present on: ...@@ -17,7 +17,7 @@ vulnerability is not present on:
- Older processor models, where the CPU family is < 6 - Older processor models, where the CPU family is < 6
- A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft, - A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
Penwell, Pineview, Slivermont, Airmont, Merrifield) Penwell, Pineview, Silvermont, Airmont, Merrifield)
- The Intel Core Duo Yonah variants (2006 - 2008) - The Intel Core Duo Yonah variants (2006 - 2008)
...@@ -113,7 +113,7 @@ Attack scenarios ...@@ -113,7 +113,7 @@ Attack scenarios
deployment scenario. The mitigations, their protection scope and impact deployment scenario. The mitigations, their protection scope and impact
are described in the next sections. are described in the next sections.
The default mitigations and the rationale for chosing them are explained The default mitigations and the rationale for choosing them are explained
at the end of this document. See :ref:`default_mitigations`. at the end of this document. See :ref:`default_mitigations`.
.. _l1tf_sys_info: .. _l1tf_sys_info:
...@@ -191,15 +191,15 @@ Guest mitigation mechanisms ...@@ -191,15 +191,15 @@ Guest mitigation mechanisms
- unconditional ('always') - unconditional ('always')
The conditional mode avoids L1D flushing after VMEXITs which execute The conditional mode avoids L1D flushing after VMEXITs which execute
only audited code pathes before the corresponding VMENTER. These code only audited code paths before the corresponding VMENTER. These code
pathes have beed verified that they cannot expose secrets or other paths have been verified that they cannot expose secrets or other
interesting data to an attacker, but they can leak information about the interesting data to an attacker, but they can leak information about the
address space layout of the hypervisor. address space layout of the hypervisor.
Unconditional mode flushes L1D on all VMENTER invocations and provides Unconditional mode flushes L1D on all VMENTER invocations and provides
maximum protection. It has a higher overhead than the conditional maximum protection. It has a higher overhead than the conditional
mode. The overhead cannot be quantified correctly as it depends on the mode. The overhead cannot be quantified correctly as it depends on the
work load scenario and the resulting number of VMEXITs. workload scenario and the resulting number of VMEXITs.
The general recommendation is to enable L1D flush on VMENTER. The kernel The general recommendation is to enable L1D flush on VMENTER. The kernel
defaults to conditional mode on affected processors. defaults to conditional mode on affected processors.
...@@ -262,7 +262,7 @@ Guest mitigation mechanisms ...@@ -262,7 +262,7 @@ Guest mitigation mechanisms
Whether the interrupts with are affine to CPUs, which run untrusted Whether the interrupts with are affine to CPUs, which run untrusted
guests, provide interesting data for an attacker depends on the system guests, provide interesting data for an attacker depends on the system
configuration and the scenarios which run on the system. While for some configuration and the scenarios which run on the system. While for some
of the interrupts it can be assumed that they wont expose interesting of the interrupts it can be assumed that they won't expose interesting
information beyond exposing hints about the host OS memory layout, there information beyond exposing hints about the host OS memory layout, there
is no way to make general assumptions. is no way to make general assumptions.
...@@ -299,7 +299,7 @@ Guest mitigation mechanisms ...@@ -299,7 +299,7 @@ Guest mitigation mechanisms
to be brought up at least partially and are then shut down to be brought up at least partially and are then shut down
again. "nosmt" can be undone via the sysfs interface. again. "nosmt" can be undone via the sysfs interface.
nosmt=force Has the same effect as "nosmt' but it does not allow to nosmt=force Has the same effect as "nosmt" but it does not allow to
undo the SMT disable via the sysfs interface. undo the SMT disable via the sysfs interface.
=========== ========================================================== =========== ==========================================================
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment