summaryrefslogtreecommitdiff
path: root/Documentation/admin-guide/hw-vuln
diff options
context:
space:
mode:
authorFabio M. De Francesco <fmdefrancesco@gmail.com>2021-07-21 21:02:50 +0200
committerJonathan Corbet <corbet@lwn.net>2021-07-25 14:39:17 -0600
commitce48ee81a1930b2218bea23490adb6673c88bf70 (patch)
tree062671c8503c1ca3f997710a0a9375a8c1039b4a /Documentation/admin-guide/hw-vuln
parentb426d9d78efb39800dabaed447a0bfc959038930 (diff)
admin-guide/hw-vuln: Rephrase a section of core-scheduling.rst
Rephrase the "For MDS" section in core-scheduling.rst for the purpose of making it clearer what is meant by "kernel memory is still considered untrusted". Suggested-by: Vineeth Pillai <Vineeth.Pillai@microsoft.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Reviewed-by: Joel Fernandes (Google) <joelaf@google.com> Link: https://lore.kernel.org/r/20210721190250.26095-1-fmdefrancesco@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/admin-guide/hw-vuln')
-rw-r--r--Documentation/admin-guide/hw-vuln/core-scheduling.rst10
1 files changed, 6 insertions, 4 deletions
diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst
index 7b410aef9c5c..0febe458597c 100644
--- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst
+++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst
@@ -181,10 +181,12 @@ Open cross-HT issues that core scheduling does not solve
--------------------------------------------------------
1. For MDS
~~~~~~~~~~
-Core scheduling cannot protect against MDS attacks between an HT running in
-user mode and another running in kernel mode. Even though both HTs run tasks
-which trust each other, kernel memory is still considered untrusted. Such
-attacks are possible for any combination of sibling CPU modes (host or guest mode).
+Core scheduling cannot protect against MDS attacks between the siblings
+running in user mode and the others running in kernel mode. Even though all
+siblings run tasks which trust each other, when the kernel is executing
+code on behalf of a task, it cannot trust the code running in the
+sibling. Such attacks are possible for any combination of sibling CPU modes
+(host or guest mode).
2. For L1TF
~~~~~~~~~~~