[MODERATED] [PATCH 1/1] SMTDOCv2 0

[Andi Kleen <andi@firstfloor.org>]

Add a document describing when and how to disable L1TF for KVM. The goal
is to avoid disabling as much as possible to keep the performance
benefits from SMT.

The warning message from KVM when SMT is on can point to this
document.

---

An open item is still how to handle interrupts for the "confined cores"
case. Right now it describes the sledge hammer of changing the affinity
of all interrupts, but that's likely not needed in all cases.
I'll send another email on this.

v2: Fix typos, fix SMT on sequence.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 Documentation/virtual/kvm/l1tf-mitigation.txt | 69 +++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/virtual/kvm/l1tf-mitigation.txt

diff --git a/Documentation/virtual/kvm/l1tf-mitigation.txt b/Documentation/virtual/kvm/l1tf-mitigation.txt
new file mode 100644
index 000000000000..c8d72d0057f0
--- /dev/null
+++ b/Documentation/virtual/kvm/l1tf-mitigation.txt
@@ -0,0 +1,69 @@
+L1TF mitigation strategies in KVM
+
+On some Intel CPUs a side channel attack may make it possible to read
+arbitrary data in the L1D cache of the CPU core in the guest, potentially allowing
+to read data from outside the VM.
+
+The Linux kernel automatically detects the conditions for this problem
+and reports the status in /sys/devices/system/cpu/vulnerabilities/l1tf.
+
+With HyperThreading (SMT) enabled the L1D cache of a core is shared between the two
+CPU threads in a core.
+
+KVM mitigates this problems transparently when SMT is disabled. With SMT
+enabled additional actions may be needed.  This document describes
+these additional actions.
+
+- When the system does not support HyperThreading no further
+effort is needed.
+
+This can be determined with
+
+% lscpu | grep Thread
+
+If the reported Thread number is 1 then HyperThreading is not
+available.
+
+- When the guest is not running any untrusted code then
+no further action is needed.
+
+- When the guest kernel is controlled by the host owner the only
+mitigation needed is to update the guest kernel to a kernel version
+with L1TF page table mitigation integrated.
+
+This will prevent any untrusted user programs running in the guest attacking
+the host, other guests, or other processes running inside the guest.
+
+When this is done no further action is needed.
+
+- When the guest is already confined to a dedicated core that
+does not run any host processes or other guests on either of its threads
+no further action is needed.
+
+The core could still in some cases process interrupts.
+
+The interrupts can be redirected to other cores using the
+/proc/irq/NUMBER/smp_affinity interface.
+
+- When the guest is not confined it can be confined to dedicated cores
+through exclusive cpusets. This does not necessarily need to be dedicated
+cores for each guest, but could be also dedicated cores for a group
+of VMs controlled by the same entity.
+
+For more details on cpusets please see Documentation/cgroup-v1/cpusets.txt
+
+- If this all fails SMT can be disabled on all cores
+
+SMT improves performance so it should be only disabled when absolutely
+needed, and reenabled after the untrusted guest is finished.
+
+To disable SMT:
+
+echo off > /sys/devices/system/cpu/smt/control
+
+To reenable after running untrusted guest
+
+echo on > /sys/devices/system/cpu/smt/control
+for i in /sys/devices/system/cpu/cpu*/online ; do
+    echo 1 > $i
+done
-- 
2.14.4