linux-kernel - Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Nov 2018 07:14:56 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Tim Chen <tim.c.chen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>, thomas.lendacky@....com,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>, dave.hansen@...el.com,
        Casey Schaufler <casey.schaufler@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>,
        "Van De Ven, Arjan" <arjan@...ux.intel.com>, jcm@...hat.com,
        longman9394@...il.com, Greg KH <gregkh@...uxfoundation.org>,
        david.c.stewart@...el.com,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        stable@...r.kernel.org
Subject: Re: [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