There were concerns with the current interface (checking for the state
of SMT of the core at opt-in time [1]). These patches change the
interface to send a SIGBUS to the task if
a. It opts into L1D flushing
b. Runs on a core with SMT enabled
There are also documentation fixes. I've tested the patches at my end,
but would appreciate a broad review of the change in functionality
and/or any recommended doc updates.
[1] http://lkml.iu.edu/hypermail/linux/kernel/2009.3/09310.html
[2] http://lkml.iu.edu/hypermail/linux/kernel/2009.3/09613.html
NOTE: For testing these patches, specifically the SIGBUS behaviour,
there needs to be contention on the CPU where the task that opts
into L1D flushing is running to see the SIGBUS being sent to it
(the deterministic bit is that if there is scope of data leak
the task will get killed)
Balbir Singh (3):
x86/mm: change l1d flush runtime prctl behaviour
Documentation: Update the new SIGBUS behaviour for tasks
Documentation/l1d_flush: Fix up warning with labels
.../admin-guide/hw-vuln/l1d_flush.rst | 12 +++---
arch/Kconfig | 4 ++
arch/x86/Kconfig | 1 +
arch/x86/mm/tlb.c | 37 +++++++++++--------
include/linux/sched.h | 10 +++++
5 files changed, 42 insertions(+), 22 deletions(-)
--
2.17.1
Add a label to spec_set_ctrl to remove the build warning.
Signed-off-by: Balbir Singh <[email protected]>
---
To be applied on top of tip commit id
767d46ab566dd489733666efe48732d523c8c332
Documentation/admin-guide/hw-vuln/l1d_flush.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
index c6a0713c8271..108bd2bdc196 100644
--- a/Documentation/admin-guide/hw-vuln/l1d_flush.rst
+++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
@@ -22,8 +22,8 @@ mechanism
Usage Guidelines
----------------
-Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst` for
-details.
+Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst
+<set_spec_ctrl>` for details.
**NOTE**: The feature is disabled by default, applications need to
specifically opt into the feature to enable it.
--
2.17.1
Update the documentation to mention that a SIGBUS will be sent
to tasks that opt-into L1D flushing and execute on non-SMT cores.
Signed-off-by: Balbir Singh <[email protected]>
---
To be applied on top of tip commit id
767d46ab566dd489733666efe48732d523c8c332
Documentation/admin-guide/hw-vuln/l1d_flush.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
index adc4ecc72361..c6a0713c8271 100644
--- a/Documentation/admin-guide/hw-vuln/l1d_flush.rst
+++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
@@ -63,8 +63,8 @@ This can be addressed by controlled placement of processes on physical CPU
cores or by disabling SMT. See the relevant chapter in the L1TF mitigation
document: :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.
-**NOTE** : Checks have been added to ensure that the prctl API associated
+**NOTE** : Checks have been added to ensure that the L1D flush associated
with the opt-in will work only when the task affinity of the task opting
-in, is limited to cores running in non-SMT mode. The same checks are made
-when L1D is flushed. Changing the affinity after opting in, would result
-in flushes not working on cores that are in non-SMT mode.
+in, is limited to cores running in non-SMT mode. Changing the affinity after
+opting in, would result in the task getting a SIGBUS when it executes on
+the flush is needed and the task is executing on the non-SMT core.
--
2.17.1