| From foo@baz Tue Aug 14 16:14:56 CEST 2018 |
| From: Tony Luck <tony.luck@intel.com> |
| Date: Thu, 19 Jul 2018 13:49:58 -0700 |
| Subject: Documentation/l1tf: Fix typos |
| |
| From: Tony Luck <tony.luck@intel.com> |
| |
| commit 1949f9f49792d65dba2090edddbe36a5f02e3ba3 upstream |
| |
| Fix spelling and other typos |
| |
| Signed-off-by: Tony Luck <tony.luck@intel.com> |
| Signed-off-by: Thomas Gleixner <tglx@linutronix.de> |
| Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> |
| Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| --- |
| Documentation/l1tf.rst | 14 +++++++------- |
| 1 file changed, 7 insertions(+), 7 deletions(-) |
| |
| --- a/Documentation/l1tf.rst |
| +++ b/Documentation/l1tf.rst |
| @@ -17,7 +17,7 @@ vulnerability is not present on: |
| - Older processor models, where the CPU family is < 6 |
| |
| - 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) |
| |
| @@ -113,7 +113,7 @@ Attack scenarios |
| deployment scenario. The mitigations, their protection scope and impact |
| 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`. |
| |
| .. _l1tf_sys_info: |
| @@ -191,15 +191,15 @@ Guest mitigation mechanisms |
| - unconditional ('always') |
| |
| The conditional mode avoids L1D flushing after VMEXITs which execute |
| - only audited code pathes before the corresponding VMENTER. These code |
| - pathes have beed verified that they cannot expose secrets or other |
| + only audited code paths before the corresponding VMENTER. These code |
| + paths have been verified that they cannot expose secrets or other |
| interesting data to an attacker, but they can leak information about the |
| address space layout of the hypervisor. |
| |
| Unconditional mode flushes L1D on all VMENTER invocations and provides |
| maximum protection. It has a higher overhead than the conditional |
| 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 |
| defaults to conditional mode on affected processors. |
| @@ -262,7 +262,7 @@ Guest mitigation mechanisms |
| Whether the interrupts with are affine to CPUs, which run untrusted |
| guests, provide interesting data for an attacker depends on the system |
| 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 |
| is no way to make general assumptions. |
| |
| @@ -299,7 +299,7 @@ Guest mitigation mechanisms |
| to be brought up at least partially and are then shut down |
| 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. |
| =========== ========================================================== |
| |