Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Sep 2018 10:45:58 -0700
From: Eric Biggers <>
To: Kristen C Accardi <>
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.