lkml.org 
[lkml]   [2018]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task
On Tue, 20 Nov 2018, Linus Torvalds wrote:

> > Implements arch_update_spec_restriction() for x86. Use STIBP to
> > restrict speculative execution when running a task set to non-dumpable,
> > or clear the restriction if the task is set to dumpable.
>
> I don't think this necessarily makes sense.
>
> The new "auto" behavior is that we aim to restrict untrusted code (and
> the loader of such code uses prctrl to set that flag), then this whole
> "set STIBP for non-dumpable" makes little sense.
>
> A non-dumpable app by definition is *more* trusted, not less trusted.

I understand your argument. I believe actually both ways of protection do
make sense in some way (but it doesn't mean we should do it by default).
Basically:

- process marks itself "I am loading untrusted code" via that prctl() in
order to avoid its untrusted code to be used as spectrev2 gadgets

- process marks itself "I am loading untrusted code" via that prctl() in
order to have its all threads/subprocesses marked the same way, so that
one thread can't influence speculative code flow of the other in order
to read its memory (the "javascript in one browser tab reads secrets
from another tab")

- non-dumpable tasks have the branch predictor flushed when
context switching to them (IBPB) or when sibling is running untrusted
code (STIBP) in order not guarantee that its speculative code flow can
never be influenced by previous / sibling process mistraining branch
predictor for it, and therefore do not allow reading its secrets from
memory through gadgets that'd have to be in the process code itself

But I agree there are many reasons why this shouldn't be done by default
if we accept 'prctl' as the default mode. Namely:

- the whole "proper gadgets need to be present in the process' .text" is
dubious by itself

- the unavoidable overhead it'd impose on network daemons that you can't
really get rid of

The distiled patchset that Thomas will be sending around today is not have
the dumpability restriction in it.

Thanks,

--
Jiri Kosina
SUSE Labs

\
 
 \ /
  Last update: 2018-11-21 07:16    [W:0.086 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site