Commit 70a9abf5 authored by Fabio M. De Francesco's avatar Fabio M. De Francesco Committed by Zheng Zengkai
Browse files

admin-guide/hw-vuln: Rephrase a section of core-scheduling.rst 

mainline inclusion
from mainline-v5.15-rc1
commit ce48ee81
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5OOWG
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce48ee81a1930b2218bea23490adb6673c88bf70



--------------------------------------------------------------------------

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: default avatarVineeth Pillai <Vineeth.Pillai@microsoft.com>
Signed-off-by: default avatarFabio M. De Francesco <fmdefrancesco@gmail.com>
Reviewed-by: default avatarJoel Fernandes (Google) <joelaf@google.com>
Link: https://lore.kernel.org/r/20210721190250.26095-1-fmdefrancesco@gmail.com


Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
Signed-off-by: default avatarLin Shengwang <linshengwang1@huawei.com>
Reviewed-by: default avatarlihua <hucool.lihua@huawei.com>
Signed-off-by: default avatarZheng Zengkai <zhengzengkai@huawei.com>
parent a6d571a5

Documentation/admin-guide/hw-vuln/core-scheduling.rst

+6 −4
Original line number Diff line number Diff line
@@ -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

~~~~~~~~~~~