linux-kernel - Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1

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:   Sun, 12 Apr 2020 13:14:04 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Bernd Edlinger <bernd.edlinger@...mail.de>,
        Waiman Long <longman@...hat.com>,
        Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexey Gladkov <gladkov.alexey@...il.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1

On Sun, Apr 12, 2020 at 12:51 PM Oleg Nesterov <oleg@...hat.com> wrote:
>
> To be honest, I don't understand it... OK, suppose that the main thread
> M execs and zap_other_threads() finds a single (and alive) sub-thread T,
> sig->notify_count = 1.
>
> If T is traced, then ->notify_count won't be decremented until the tracer
> reaps this task, so we have the same problem.

Right you are.

I was hoping to avoid the "move notify_count update", but you're
right, the threads that do get properly killed will never get to that
point, so now the live ones that we're waiting for will just hit the
same issue that the dead ones did.

Goot catch. So the optimistic simplification doesn't work.

> > You do say in that old patch that we can't just share the signal
> > state, but I wonder how true that is.
>
> We can share sighand_struct with TASK_ZOMBIE's. The problem is that
> we can not unshare ->sighand until they go away, execing thread and
> zombies must use the same sighand->siglock to serialize the access to
> ->thread_head/etc.

Yeah, they'll still touch the lock, and maybe look at it, but it's not
like they'll be changing any state.

> but see above, I don't think this makes any sense.

Yeah, I think your patch is better since my simplification doesn't work.

             Linus