linux-kernel - Re: [PATCH v2 3/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:   Tue, 19 May 2020 23:41:23 +0000
From:   "Singh, Balbir" <sblbir@...zon.com>
To:     "keescook@...omium.org" <keescook@...omium.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "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 v2 3/4] arch/x86: Optionally flush L1D on context switch

On Tue, 2020-04-07 at 11:26 -0700, Kees Cook wrote:
> 
> 
> On Mon, Apr 06, 2020 at 01:19:45PM +1000, Balbir Singh wrote:
> > Implement a mechanism to selectively flush the 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.
> > 
> > There are two scenarios we might want to protect against, a task leaving
> > the CPU with data still in L1D (which is the main concern of this patch),
> > the second scenario is a malicious task coming in (not so well trusted)
> > for which we want to clean up the cache before it starts. Only the case
> > for the former is addressed.
> > 
> > Add arch specific prctl()'s to opt-in to the L1D cache on context switch
> > out, the existing mechanisms of tracking prev_mm via cpu_tlbstate is
> > reused. cond_ibpb() is refactored and renamed into cond_mitigation().
> 
> I still think this should be a generic prctl(). If there is a strong
> reason not to do this, can it be described in the commit log here?

Kees, the context in the changelog might be misleading, the prctl is generic,
the implementation is arch specific as you can see from the following patches.
I can reword the change log, sorry for the confusion.

Balbir Singh.