[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1536773389.3240.4.camel@linux.intel.com>
Date: Wed, 12 Sep 2018 10:29:49 -0700
From: Kristen C Accardi <kristen@...ux.intel.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH] x86: entry: flush the cache if syscall error
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), and
worst case this would just mean we were wiping the wrong cache. I can
add a comment to indicate this scenario.
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.
