Date: Wed, 12 Sep 2018 10:45:58 -0700 From: Eric Biggers <ebiggers@...nel.org> To: Kristen C Accardi <kristen@...ux.intel.com> Cc: kernel-hardening@...ts.openwall.com Subject: Re: [RFC PATCH] x86: entry: flush the cache if syscall error On Wed, Sep 12, 2018 at 10:29:49AM -0700, Kristen C Accardi wrote: > On Tue, 2018-09-11 at 09:06 -0700, Eric Biggers wrote: > > On Mon, Sep 10, 2018 at 12:10:02PM -0700, Kristen Carlson Accardi > > wrote: > > > This patch aims to make it harder to perform cache timing attacks > > > on data > > > left behind by system calls. If we have an error returned from a > > > syscall, > > > flush the L1 cache. > > > > Which L1 cache? There's no guarantee the task stayed on the same > > CPU... > > While this is true, it is unlikely that the task switched CPUs for this > type of flow (i.e. an error path, presumably caught early-ish), How you do know it's unlikely? What degrees of freedom might an attacker have in controlling this? > worst case this would just mean we were wiping the wrong cache. I can > add a comment to indicate this scenario. > IOW, the protection may be useless? - Eric
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.