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]

Message-ID: <aeeab5d3-c2cf-e6a5-9da3-d14d30e79011@linux.intel.com>
Date:   Wed, 21 Nov 2018 09:41:31 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Jiri Kosina <jikos@...nel.org>,
        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 11/20/2018 05:27 PM, Linus Torvalds wrote:
> On Tue, Nov 20, 2018 at 4:33 PM Tim Chen <tim.c.chen@...ux.intel.com> 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.

When STIBP is on, it will prevent not only untrusted code from attacking,
but also trusted code from getting attacked.  So non-dumpable task running
with STIBP will protect itself from attacks from code running on sibling CPU.

>From software guidance:
"Setting ... STIBP ... on a logical processor prevents the predicted
targets of indirect branches on any logical processor of that core
from being controlled by software that executes (or executed
previously) on another logical processor of the same core."

The intention was to put TIF_SPEC_INDIR_BRANCH flag on
non-dumpable task, so it runs with STIBP and prevent
itself from getting attacked from code running in sibling CPU.  
And when we context switch to non-dumpable task,
IBPB will be issued to prevent attack from anything running
on the same cpu based on TIF_SPEC_INDIR_BRANCH.

> 
> A non-dumpable app by definition is *more* trusted, not less trusted.
> 
> So this model of "let's disable prediction for system processes" not
> only doesn't make sense, but it also unnecessarily penalizes those
> potentially very important system processes.

It is a trade off of extra protection for non-dumpable app with
extra overhead. :(

Here it is the default behavior but that can be changed.

If we don't erect STIBP for non-dumpable tasks as default, we should still do IBPB
before switching to them.  So the STIBP behavior and IBPB behavior will
then be untied for non-dumpable default.

> 
> Also, "dumpable" in general is pretty oddly defined to be used for this.
> 
> The same (privileged) process can be dumpable or not depending on how
> it was started (ie if it was started by a regular user and became
> trusted through suid, it's not dumpable, but if it was started from a
> root process it remains dumpable.
> 
> So I'm just not convinced "dumpability" is meaningful for STIBP.
> 

Tim