[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 12 Sep 2018 14:19:18 -0400
From: Rik van Riel <riel@...riel.com>
To: Eric Biggers <ebiggers@...nel.org>, 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, 2018-09-12 at 10:45 -0700, Eric Biggers wrote:
> 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?
If the task gets moved to a different CPU, won't that
completely foil a timing attack?
In other words, this protection would protect against
an attack on the same CPU, and is unnecessary when a
task switches CPUs?
What am I missing?
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
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.
