From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>, Ingo Molnar <mingo@kernel.org>,
Will Deacon <will@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexey Gladkov <gladkov.alexey@gmail.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
Date: Wed, 8 Apr 2020 17:21:05 +0200 [thread overview]
Message-ID: <AM6PR03MB517015F585466ED40113FDEEE4C00@AM6PR03MB5170.eurprd03.prod.outlook.com> (raw)
In-Reply-To: <87v9maxb5q.fsf@x220.int.ebiederm.org>
On 4/8/20 5:14 PM, Eric W. Biederman wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Mon, Apr 6, 2020 at 3:20 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>>
>>> But fundamentally the only reason we need this information stable
>>> before the point of no return is so that we can return a nice error
>>> code to the process calling exec. Instead of terminating the
>>> process with SIGSEGV.
>>
>> I'd suggest doing it the other way around instead: let the thread that
>> does the security_setprocattr() die, since execve() is terminating
>> other threads anyway.
>>
>> And the easy way to do that is to just make the rule be that anybody
>> who waits for this thing for write needs to use a killable wait.
>>
>> So if the execve() got started earlier, and already took the cred lock
>> (whatever we'll call it) for reading, then zap_other_threads() will
>> take care of another thread doing setprocattr().
>>
>> That sounds like a really simple model, no?
>
> Yes. I missed the fact that we could take the lock killable.
> We still unfortunately have the deadlock with ptrace.
>
> It might be simpler to make whichever lock we are dealing with per
> task_struct instead of per signal_struct. Then we don't even have to
> think about what de_thread does or if the lock is taken killable.
>
I think you said that already, but I did not understand the difference,
could you please give some more details about your idea?
Thanks
Bernd.
>
> Looking at the code in binfmt_elf.c there are about 11 other places
> after install_exec_creds where we can fail and would be forced to
> terminate the application with SIGSEGV instead of causing fork to fail.
>
>
>
>
> I keep wondering if we could do something similar to vfork. That is
> allocate an new task_struct and fully set it up for the post exec
> process, and then make it visible under tasklist_lock. Finally we could
> free the old process.
>
> That would appear as if everything happened atomically from
> the point of view of the rest of the kernel.
>
> As well as fixing all of the deadlocks and making it easy
> to ensure we don't have any more weird failures in the future.
>
> Eric
>
> p.s. For tasklist_lock I suspect we can put a lock in struct pid
> and use that to guard the task lists in struct pid. Which would
> allow for tasklist_lock to be take much less. Then we would
> just need a solution for task->parent and task->real_parent and
> I think all of the major users of tasklist_lock would be gone.
>
>
next prev parent reply other threads:[~2020-04-08 15:21 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87blobnq02.fsf@x220.int.ebiederm.org>
2020-04-02 19:04 ` [GIT PULL] Please pull proc and exec work for 5.7-rc1 Linus Torvalds
2020-04-02 19:31 ` Bernd Edlinger
2020-04-02 19:52 ` Linus Torvalds
2020-04-02 20:59 ` Bernd Edlinger
2020-04-02 21:46 ` Linus Torvalds
2020-04-02 23:01 ` Eric W. Biederman
2020-04-02 23:42 ` Bernd Edlinger
2020-04-02 23:45 ` Eric W. Biederman
2020-04-02 23:49 ` Bernd Edlinger
2020-04-02 23:45 ` Linus Torvalds
2020-04-02 23:44 ` Linus Torvalds
2020-04-03 0:05 ` Eric W. Biederman
2020-04-07 1:29 ` [RFC][PATCH 0/3] exec_update_mutex related cleanups Eric W. Biederman
2020-04-07 1:31 ` [PATCH 1/3] binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf Eric W. Biederman
2020-04-07 15:58 ` Kees Cook
2020-04-07 16:11 ` Christian Brauner
2020-04-08 17:25 ` Linus Torvalds
2020-04-08 19:51 ` Eric W. Biederman
2020-04-07 1:31 ` [PATCH 2/3] exec: Make unlocking exec_update_mutex explict Eric W. Biederman
2020-04-07 16:02 ` Kees Cook
2020-04-07 16:17 ` Christian Brauner
2020-04-07 16:21 ` Eric W. Biederman
2020-04-07 1:32 ` [PATCH 3/3] exec: Rename the flag called_exec_mmap point_of_no_return Eric W. Biederman
2020-04-07 16:03 ` Kees Cook
2020-04-07 16:21 ` Christian Brauner
2020-04-07 16:22 ` [RFC][PATCH 0/3] exec_update_mutex related cleanups Christian Brauner
2020-04-08 17:26 ` Linus Torvalds
2020-04-03 5:09 ` [GIT PULL] Please pull proc and exec work for 5.7-rc1 Bernd Edlinger
2020-04-03 19:26 ` Linus Torvalds
2020-04-03 20:41 ` Waiman Long
2020-04-03 20:59 ` Linus Torvalds
2020-04-03 23:16 ` Waiman Long
2020-04-03 23:23 ` Waiman Long
2020-04-04 1:30 ` Linus Torvalds
2020-04-04 2:02 ` Waiman Long
2020-04-04 2:28 ` Linus Torvalds
2020-04-04 6:34 ` Bernd Edlinger
2020-04-05 6:34 ` Bernd Edlinger
2020-04-05 19:35 ` Linus Torvalds
2020-04-05 2:42 ` Waiman Long
2020-04-05 3:35 ` Bernd Edlinger
2020-04-05 3:45 ` Waiman Long
2020-04-06 13:13 ` Will Deacon
2020-04-04 4:23 ` Bernd Edlinger
2020-04-06 22:17 ` Eric W. Biederman
2020-04-07 19:50 ` Linus Torvalds
2020-04-07 20:29 ` Bernd Edlinger
2020-04-07 20:47 ` Linus Torvalds
2020-04-08 15:14 ` Eric W. Biederman
2020-04-08 15:21 ` Bernd Edlinger [this message]
2020-04-08 16:34 ` Linus Torvalds
2020-04-09 14:58 ` Eric W. Biederman
2020-04-09 15:15 ` Bernd Edlinger
2020-04-09 16:15 ` Linus Torvalds
2020-04-09 16:24 ` Linus Torvalds
2020-04-09 17:03 ` Eric W. Biederman
2020-04-09 17:17 ` Bernd Edlinger
2020-04-09 17:37 ` Linus Torvalds
2020-04-09 17:46 ` Bernd Edlinger
2020-04-09 18:36 ` Linus Torvalds
2020-04-09 19:42 ` Linus Torvalds
2020-04-09 19:57 ` Bernd Edlinger
2020-04-09 20:04 ` Linus Torvalds
2020-04-09 20:36 ` Bernd Edlinger
2020-04-09 21:00 ` Eric W. Biederman
2020-04-09 21:17 ` Linus Torvalds
2020-04-09 23:52 ` Bernd Edlinger
2020-04-10 0:30 ` Linus Torvalds
2020-04-10 0:32 ` Linus Torvalds
2020-04-11 4:07 ` Bernd Edlinger
2020-04-11 18:20 ` Oleg Nesterov
2020-04-11 18:29 ` Linus Torvalds
2020-04-11 18:31 ` Linus Torvalds
2020-04-11 19:15 ` Bernd Edlinger
2020-04-11 20:07 ` Linus Torvalds
2020-04-11 21:16 ` Bernd Edlinger
[not found] ` <CAHk-=wgWHkBzFazWJj57emHPd3Dg9SZHaZqoO7-AD+UbBTJgig@mail.gmail.com>
2020-04-11 21:57 ` Linus Torvalds
2020-04-12 6:01 ` Bernd Edlinger
2020-04-12 19:50 ` Oleg Nesterov
2020-04-12 20:14 ` Linus Torvalds
2020-04-28 2:56 ` Bernd Edlinger
2020-04-28 17:07 ` Linus Torvalds
2020-04-28 19:08 ` Oleg Nesterov
2020-04-28 20:35 ` Linus Torvalds
2020-04-28 21:06 ` Jann Horn
2020-04-28 21:36 ` Linus Torvalds
2020-04-28 21:53 ` Jann Horn
2020-04-28 22:14 ` Linus Torvalds
2020-04-28 23:36 ` Jann Horn
2020-04-29 17:58 ` Linus Torvalds
2020-04-29 18:33 ` Jann Horn
2020-04-29 18:57 ` Linus Torvalds
2020-04-29 19:23 ` Bernd Edlinger
2020-04-29 19:26 ` Jann Horn
2020-04-29 20:19 ` Bernd Edlinger
2020-04-29 21:06 ` Jann Horn
2020-04-29 22:38 ` Linus Torvalds
2020-04-29 23:22 ` Linus Torvalds
2020-04-29 23:59 ` Jann Horn
2020-04-30 1:08 ` Bernd Edlinger
2020-04-30 2:20 ` Linus Torvalds
2020-04-30 3:00 ` Jann Horn
2020-04-30 3:25 ` Linus Torvalds
2020-04-30 3:41 ` Jann Horn
2020-04-30 3:50 ` Linus Torvalds
2020-04-30 13:37 ` Linus Torvalds
2020-04-30 2:16 ` Linus Torvalds
2020-04-30 13:39 ` Bernd Edlinger
2020-04-30 13:47 ` Linus Torvalds
2020-04-30 14:29 ` Bernd Edlinger
2020-04-30 16:40 ` Linus Torvalds
2020-05-02 4:11 ` Bernd Edlinger
2020-04-09 17:36 ` Linus Torvalds
2020-04-09 20:34 ` Eric W. Biederman
2020-04-09 20:56 ` Linus Torvalds
2020-04-02 23:02 ` Bernd Edlinger
2020-04-02 23:22 ` Bernd Edlinger
2020-04-03 7:38 ` Bernd Edlinger
2020-04-03 16:00 ` Bernd Edlinger
2020-04-03 15:09 ` Bernd Edlinger
2020-04-03 16:23 ` Linus Torvalds
2020-04-03 16:36 ` Bernd Edlinger
2020-04-04 5:43 ` Bernd Edlinger
2020-04-04 5:48 ` Bernd Edlinger
2020-04-06 6:41 ` Bernd Edlinger
2020-04-10 13:03 ` [GIT PULL] proc fix " Eric W. Biederman
2020-04-10 20:40 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM6PR03MB517015F585466ED40113FDEEE4C00@AM6PR03MB5170.eurprd03.prod.outlook.com \
--to=bernd.edlinger@hotmail.de \
--cc=ebiederm@xmission.com \
--cc=gladkov.alexey@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).