[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kernel-hardening
Subject:    Re: [RFC PATCH] x86: entry: flush the cache if syscall error
From:       Rik van Riel <riel () surriel ! com>
Date:       2018-09-12 18:19:18
Message-ID: cf545f1e8fb4d77b6ec675a7f78268dc22d9aa90.camel () surriel ! com
[Download RAW message or body]


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.

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]