On Wed, 2020-05-13 at 15:33 +0200, Thomas Gleixner wrote: > > > Balbir Singh <sbl...@amazon.com> writes: > > +With an increasing number of vulnerabilities being reported around > > data > > +leaks from L1D, a new user space mechanism to flush the L1D cache > > on > > +context switch is added to the kernel. This should help address > > is added to the kernel? This is documentation of an existing > feature... >
Good catch! Thanks > > +Mitigation > > +---------- > > +When PR_SET_L1D_FLUSH is enabled for a task, on switching tasks > > (when > > +the address space changes), a flush of the L1D cache is performed > > for > > +the task when it leaves the CPU. If the underlying CPU supports L1D > > +flushing in hardware, the hardware mechanism is used, otherwise a > > software > > +fallback, similar to the mechanism used by L1TF is used. > > This lacks documentation of the limitations, especially that this does > not help against cross Hyperthread attacks. > Yes, true > I've massaged the whole thing a bit. See below. > > Thanks, > > tglx > 8<----------------- > > --- a/Documentation/admin-guide/hw-vuln/index.rst > +++ b/Documentation/admin-guide/hw-vuln/index.rst > @@ -14,3 +14,4 @@ are configurable at compile, boot or run > mds > tsx_async_abort > multihit.rst > + l1d_flush > --- /dev/null > +++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst > @@ -0,0 +1,53 @@ > +L1D Flushing for the paranoid > +============================= > + > +With an increasing number of vulnerabilities being reported around > data > +leaks from the Level 1 Data cache (L1D) the kernel provides an opt-in > +mechanism to flush the L1D cache on context switch. > + > +This mechanism can be used to address e.g. CVE-2020-0550. For > paranoid > +applications the mechanism keeps them safe from any yet to be > discovered > +vulnerabilities, related to leaks from the L1D cache. > + > + > +Related CVEs > +------------ > +At the present moment, the following CVEs can be addressed by this > +mechanism > + > + ============= ======================== ================ > == > + CVE-2020-0550 Improper Data Forwarding OS related > aspects > + ============= ======================== ================ > == > + > +Usage Guidelines > +---------------- > +Applications can call ``prctl(2)`` with one of these two arguments > + > +1. PR_SET_L1D_FLUSH - flush the L1D cache on context switch (out) > +2. PR_GET_L1D_FLUSH - get the current state of the L1D cache flush, > returns 1 > + if set and 0 if not set. > + > +**NOTE**: The feature is disabled by default, applications need to > +specifically opt into the feature to enable it. > + > +Mitigation > +---------- > + > +When PR_SET_L1D_FLUSH is enabled for a task a flush of the L1D cache > is > +performed when the task is scheduled out and the incoming task > belongs to a > +different process and therefore to a different address space. > + > +If the underlying CPU supports L1D flushing in hardware, the hardware > +mechanism is used, otherwise a software fallback, similar to the L1TF > +mitigation, is invoked. > + > +Limitations > +----------- > + > +The mechanism does not mitigate L1D data leaks between tasks > belonging to > +different processes which are concurrently executing on sibling > threads of > +a physical CPU core when SMT is enabled on the system. > + > +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>`. I like your addition above Thanks, Balbir Singh.
