lkml.org 
[lkml]   [2018]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
> > From: Tim Chen <tim.c.chen@linux.intel.com>
> >
> > Flush indirect branches when switching into a process that marked
> > itself non dumpable. This protects high value processes like gpg
> > better, without having too high performance overhead.
>
> So if I understand it right, this is only needed if the 'other'
> executable itself is susceptible to spectre. If say someone audited gpg
> for spectre-v1 and build it with retpoline, it would be safe to not
> issue the IBPB, right?
>
> So would it make sense to provide an ELF flag / personality thing such
> that userspace can indicate its spectre-safe?
>
> I realize that this is all future work, because so far auditing for v1
> is a lot of pain (we need better tools), but would it be something that
> makes sense in the longer term?

So if it's only about the scheduler barrier, what cycle cost are we talking about
here?

Because putting something like this into an ELF flag raises the question of who is
allowed to set the flag - does a user-compiled binary count? If yes then it would
be a trivial thing for local exploits to set the flag and turn off the barrier.

Yes, we could make a distinction based on the owner of the file, we could use
security labels, etc. - but it gets somewhat awkward and fragile.

So unless we are talking about measurably high scheduler costs here, I'd prefer to
err on the side of caution (and simplicity) and issue the barrier unconditionally.

Thanks,

Ingo

\
 
 \ /
  Last update: 2018-01-21 17:22    [W:0.085 / U:5.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site