L!TF Bulletin #5: The state of the horrors

L!TF Bulletin #5: The state of the horrors

[Thomas Gleixner]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

Hi!

The repository has been updated with the following changes since bulletin #4:

Jiri Kosina (1):
      x86/speculation/l1tf: Unbreak !__HAVE_ARCH_PFN_MODIFY_ALLOWED architectures

Nicolai Stange (1):
      x86/KVM/VMX: Initialize the vmx_l1d_flush_pages' content

The master branch is still based on 4.18-rc1. Git bundle against v4.18-rc1
is attached.

Thanks,

	tglx

[-- Attachment #2: Type: application/octet-stream, Size: 84516 bytes --]

[MODERATED] Re: L!TF Bulletin #5: The state of the horrors (patch for some typos)

[Luck, Tony]

diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
index f2bb28cff439..ccf649cabdcd 100644
--- a/Documentation/admin-guide/l1tf.rst
+++ b/Documentation/admin-guide/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.
      =========== ==========================================================
 

Re: L!TF Bulletin #5: The state of the horrors (patch for some typos)

[Thomas Gleixner]

yOn Thu, 19 Jul 2018, speck for Luck, Tony wrote:

Could you please provide a subject, short changelog and an SOB please?

Thanks,

	tglx

> diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
> index f2bb28cff439..ccf649cabdcd 100644
> --- a/Documentation/admin-guide/l1tf.rst
> +++ b/Documentation/admin-guide/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.
>       =========== ==========================================================
>  
> 

[MODERATED] Re: L!TF Bulletin #5: The state of the horrors (patch for some typos)

[Luck, Tony]

From 5997c5cfd3066f90764d485a1dadaa94c0cee271 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Thu, 19 Jul 2018 13:49:58 -0700
Subject: [PATCH] docs/l1tf: Fix typos

Fix spelling and other typos

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 Documentation/admin-guide/l1tf.rst | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/admin-guide/l1tf.rst b/Documentation/admin-guide/l1tf.rst
index f2bb28cff439..ccf649cabdcd 100644
--- a/Documentation/admin-guide/l1tf.rst
+++ b/Documentation/admin-guide/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.
      =========== ==========================================================
 
-- 
2.17.1

Re: L!TF Bulletin #5: The state of the horrors (patch for some typos)

[Thomas Gleixner]

On Thu, 19 Jul 2018, speck for Luck, Tony wrote:
> From: Tony Luck <tony.luck@intel.com>
> Date: Thu, 19 Jul 2018 13:49:58 -0700
> Subject: [PATCH] docs/l1tf: Fix typos
> 
> Fix spelling and other typos
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>

Applied to all branches and pushed out.

Thanks,

	tglx