On Wed, 2020-05-13 at 15:33 +0200, Thomas Gleixner wrote:
>
>
> Balbir Singh 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
> `.
I like your addition above
Thanks,
Balbir Singh.
