|
| 1 | +L1D Flushing |
| 2 | +============ |
| 3 | + |
| 4 | +With an increasing number of vulnerabilities being reported around data |
| 5 | +leaks from the Level 1 Data cache (L1D) the kernel provides an opt-in |
| 6 | +mechanism to flush the L1D cache on context switch. |
| 7 | + |
| 8 | +This mechanism can be used to address e.g. CVE-2020-0550. For applications |
| 9 | +the mechanism keeps them safe from vulnerabilities, related to leaks |
| 10 | +(snooping of) from the L1D cache. |
| 11 | + |
| 12 | + |
| 13 | +Related CVEs |
| 14 | +------------ |
| 15 | +The following CVEs can be addressed by this |
| 16 | +mechanism |
| 17 | + |
| 18 | + ============= ======================== ================== |
| 19 | + CVE-2020-0550 Improper Data Forwarding OS related aspects |
| 20 | + ============= ======================== ================== |
| 21 | + |
| 22 | +Usage Guidelines |
| 23 | +---------------- |
| 24 | + |
| 25 | +Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst |
| 26 | +<set_spec_ctrl>` for details. |
| 27 | + |
| 28 | +**NOTE**: The feature is disabled by default, applications need to |
| 29 | +specifically opt into the feature to enable it. |
| 30 | + |
| 31 | +Mitigation |
| 32 | +---------- |
| 33 | + |
| 34 | +When PR_SET_L1D_FLUSH is enabled for a task a flush of the L1D cache is |
| 35 | +performed when the task is scheduled out and the incoming task belongs to a |
| 36 | +different process and therefore to a different address space. |
| 37 | + |
| 38 | +If the underlying CPU supports L1D flushing in hardware, the hardware |
| 39 | +mechanism is used, software fallback for the mitigation, is not supported. |
| 40 | + |
| 41 | +Mitigation control on the kernel command line |
| 42 | +--------------------------------------------- |
| 43 | + |
| 44 | +The kernel command line allows to control the L1D flush mitigations at boot |
| 45 | +time with the option "l1d_flush=". The valid arguments for this option are: |
| 46 | + |
| 47 | + ============ ============================================================= |
| 48 | + on Enables the prctl interface, applications trying to use |
| 49 | + the prctl() will fail with an error if l1d_flush is not |
| 50 | + enabled |
| 51 | + ============ ============================================================= |
| 52 | + |
| 53 | +By default the mechanism is disabled. |
| 54 | + |
| 55 | +Limitations |
| 56 | +----------- |
| 57 | + |
| 58 | +The mechanism does not mitigate L1D data leaks between tasks belonging to |
| 59 | +different processes which are concurrently executing on sibling threads of |
| 60 | +a physical CPU core when SMT is enabled on the system. |
| 61 | + |
| 62 | +This can be addressed by controlled placement of processes on physical CPU |
| 63 | +cores or by disabling SMT. See the relevant chapter in the L1TF mitigation |
| 64 | +document: :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`. |
| 65 | + |
| 66 | +**NOTE** : The opt-in of a task for L1D flushing works only when the task's |
| 67 | +affinity is limited to cores running in non-SMT mode. If a task which |
| 68 | +requested L1D flushing is scheduled on a SMT-enabled core the kernel sends |
| 69 | +a SIGBUS to the task. |
0 commit comments