linux-kernel - Re: [Patch v4 17/18] x86/speculation: Update SPEC

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: <738a6c7d-6ed0-a44c-e754-34758e360bed@linux.intel.com>
Date:   Wed, 7 Nov 2018 16:22:47 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Tom Lendacky <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 <dave.hansen@...el.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Kees Cook <keescook@...omium.org>
Subject: Re: [Patch v4 17/18] x86/speculation: Update SPEC_CTRL MSRs of remote
 CPUs

Thomas,

> 
> The goal is to glue the mitigation decision on dumpable. That's debatable,
> but understandable, so let's not go into that discussion.
> 
> There are two ways to modify dumpable:
> 
>   1) prctl(PR_SET_DUMPABLE)
> 
>   2) operations which change UID/GID and end up in commit_creds()
> 
> Now the really interesting question is _when_ is any of the above invoked:
> 
>   1) When the process is still single threaded ?
> 
>   2) When the process has already spawned threads ?
> 


The UID/GID changes in setuid and setgid syscalls are applied to the
thread only.  There's no propagation of the cred change to other 
related threads.  So if the user process expect the change to propagate
to other related threads, they should do setuid/setgid before they spawn
other threads.

I think similar logic should apply for prctl(PR_SET_DUMPABLE) that
the user expects the change to be for the current task and the
propagation of this change to other threads is a side effect.

Will anyone mind if we put in restriction that prctl(PR_SET_DUMPABLE)
should only be done when a task is single threaded?

Otherwise the user process should only expect the current thread to get the 
benefit of STIBP protection when setting it to non-dumpable.  I can
add comments in the code to explain this.


> If #2 is just the oddball exception, then why on earth should we go through
> loops and hoops to make it work and add overhead in hot paths for no real
> value?
> 

I tend to agree with you on this.

> So what we really want before discussing any potential solutions and their
> pro and cons is an answer to that.
> 
> If we don't have that answer, then we might just create a purely academic
> solution which creates more problems than it solves.
> 

Thanks.

Tim