linux-kernel - Re: [RFC PATCH v2 0/4] arch/x86: Optionally flush L1D on context switch

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:   Mon, 30 Mar 2020 01:13:46 +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>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>
Subject: Re: [RFC PATCH v2 0/4] arch/x86: Optionally flush L1D on context
 switch

On Wed, 2020-03-25 at 18:10 +1100, Balbir Singh wrote:
> This patch is a continuation of RFC/PoC to start the discussion on
> optionally
> flushing L1D cache.  The goal is to allow tasks that are paranoid due to the
> recent snoop assisted data sampling vulnerabilites, to flush their L1D on
> being
> switched out.  This protects their data from being snooped or leaked via
> side channels after the task has context switched out.
> 
> The points of discussion/review are (with updates):
> 
> 1. Discuss the use case and the right approach to address this
> A. Generally there seems to be consensus that we need this
> 
> 2. Does an arch prctl allowing for opt-in flushing make sense, would other
>    arches care about something similar?
> A. We definitely build this for x86, have not heard from any other arch
>    maintainers. There was suggestion to make this a prctl and let each
>    arch implement L1D flushing if needed, there is no arch agnostic
>    software L1D flush.
> 
> 3. There is a fallback software L1D load, similar to what L1TF does, but
>    we don't prefetch the TLB, is that sufficient?
> A. There was no conclusion, I suspect we don't need this
> 
> 4. Should we consider cleaning up the L1D on arrival of tasks?
> A. For now, we think this case is not the priority for this patchset.
> 
> In summary, this is an early PoC to start the discussion on the need for
> conditional L1D flushing based on the security posture of the
> application and the sensitivity of the data it has access to or might
> have access to.
> 
> Changelog v2:
>  - Reuse existing code for allocation and flush
>  - Simplify the goto logic in the actual l1d_flush function
>  - Optimize the code path with jump labels/static functions
> 
> Cc: keescook@...omium.org
> 
> Balbir Singh (4):
>   arch/x86/kvm: Refactor l1d flush lifecycle management
>   arch/x86: Refactor tlbflush and l1d flush
>   arch/x86: Optionally flush L1D on context switch
>   arch/x86: L1D flush, optimize the context switch
> 

Ping, looking for comments and criticism of the approach. I understand with
the merge window around the corner everyone is busy. There is a bug in the v2
RFC series, I am happy to post a version without the RFC for broader testing
and feedback.

I am quite keen to hear about the interface and any concerns with the
arch_prctl() interface.

Balbir Singh.