On Wed, Jul 21, 2021 at 3:02 PM Fabio M. De Francesco <fmdefrancesco@xxxxxxxxx> wrote: > > 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@xxxxxxxxxxxxx> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@xxxxxxxxx> Reviewed-by: Joel Fernandes (Google) <joelaf@xxxxxxxxxx> thanks, - Joel > --- > Documentation/admin-guide/hw-vuln/core-scheduling.rst | 9 +++++---- > 1 file changed, 5 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..e6b5ceb219ec 100644 > --- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst > +++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst > @@ -181,10 +181,11 @@ 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 > ~~~~~~~~~~~ > -- > 2.32.0 >
