Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181203123857.GS31738@dhcp22.suse.cz> <20181203131006.GA10054@amd>
 <20181203135351.GU31738@dhcp22.suse.cz> <20181203141459.GA14789@amd>
 <20181203141737.GY31738@dhcp22.suse.cz> <20181204090228.GC73770@gmail.com>
 <20181204091020.GD1286@dhcp22.suse.cz> <20181204093310.GE73770@gmail.com>
 <20181204095802.GF1286@dhcp22.suse.cz> <CAHk-=wgaEw566btStrWE+NOgPJLn1whS-Yw1-=K2Qr6MDvSZ+A@mail.gmail.com>
 <20181204181714.GR1286@dhcp22.suse.cz> <CAHk-=wh128U4GxVeHa+z_5sB52ZVXhzt0__LQq4asZgh8VtvBw@mail.gmail.com>
In-Reply-To: <CAHk-=wh128U4GxVeHa+z_5sB52ZVXhzt0__LQq4asZgh8VtvBw@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 4 Dec 2018 11:49:44 -0800
Message-ID: <CAHk-=wg1geOzkaDUVuxW-qHxhqrtpx-iCvd+e1TxZQ_AmTtn0w@mail.gmail.com>
Subject: Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
To:     mhocko@kernel.org
Cc:     Ingo Molnar <mingo@kernel.org>, pavel@ucw.cz,
        Oleg Nesterov <oleg@redhat.com>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        rafael.j.wysocki@intel.com, chanho.min@lge.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 4, 2018 at 11:33 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Looking at this, I'm agreeing that ot would be better to just try to
> narrow down the cred_guard_mutex use a lot.

Ho humm. This is a crazy idea, but I don't see why it wouldn't work.

How about we:

 - stop holding on to cred_guard_mutex entirely in the exec path

and instead just do:

 - prepare_bprm_creds takes a ref to our old creds, and saves it off in the bprm

 - security_bprm_{committing,committed}_creds() can do it's "is this a
valid transition" using the saved-off old creds instead of the current
creds

because honestly, the *only* reason we hold on to that lock is for the
insane and not really interesting case of "somebody tried to use
ptrace to change the creds in-flight during the exec".

Or maybe we could just add a task state flag that says "in exec, you
can't modify the creds in this window, because we're about to switch
to new creds".

Again, no *normal* situation will even notice or care, I think. We
hold the cred lock purely to make sure that the sequence from
prepare_exec_creds -> install_exec_creds is "atomic" wrt credentials,
and it already is for all the normal cases since this is all inside a
single execve system call.

               Linus