linux-kernel - Re: [RFC PATCH] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <f5f6bca2ccbbd3d5a82209a02ebf64834d1fe8fb.camel@amazon.com>
Date:   Mon, 23 Mar 2020 00:12:18 +0000
From:   "Singh, Balbir" <sblbir@...zon.com>
To:     "Herrenschmidt, Benjamin" <benh@...zon.com>,
        "luto@...capital.net" <luto@...capital.net>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH] arch/x86: Optionally flush L1D on context switch

On Sun, 2020-03-22 at 08:10 -0700, Andy Lutomirski wrote:
> 
> > I still think flushing the "high value" process L1D on switch_mm out is
> > the way to go here...
> 
> Let me try to understand the issue. There is some high-value data, and that
> data is owned by a high-value process. At some point, the data ends up in
> L1D.  Later in, evil code runs and may attempt to exfiltrate  that data from
> L1D using a side channel. (The evil code is not necessarily in a malicious
> process context. It could be kernel code targeted by LVI or similar. It
> could be ordinary code that happens to contain a side channel gadget by
> accident.)
> 
> So the idea is to flush L1D after manipulating high-value data and before
> running evil code.
> 
> The nasty part here is that we don’t have a good handle on when L1D is
> filled and when the evil code runs. If the evil code is untrusted process
> userspace and the fill is an interrupt, then switch_mm is useless and we
> want to flush on kernel exit instead. If the fill and evil code are both
> userspace, then switch_mm is probably the right choice, but
> prepare_exit_from_usermode works too. If SMT is on, we lose no matter
> what.  If the evil code is in kernel context, then it’s not clear what to
> do. If the fill and the evil code are both in kernel threads (hi, io_uring),
> then I’m not at all sure what to do.
> 
> In summary, kernel exit seems stronger, but the right answer isn’t so clear.
> 
> We could do an optimized variant where we flush at kernel exit but we
> *decide* to flush in switch_mm.

I think the key question in the LVI case would be, is it possible to do an LVI
in a kernel context? If the answer is no, switch_mm() is sufficient, but for
now these patches focus on flushing L1D on task exit, we could add the use
case for LVI (which is called out)

Balbir Singh.