linux-kernel - Re: [PATCH v6 6/6] Documentation: Add L1D flushing Documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 May 2020 01:12:37 +0000
From:   "Singh, Balbir" <sblbir@...zon.com>
To:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "keescook@...omium.org" <keescook@...omium.org>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>
Subject: Re:  [PATCH v6 6/6] Documentation: Add L1D flushing Documentation

On Wed, 2020-05-13 at 15:33 +0200, Thomas Gleixner wrote:
> 
> 
> Balbir Singh <sblbir@...zon.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.