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]

Message-ID: <CAHk-=wiDm68i2sT3xNm-JdwmqAYzeQHTDZzEzm-NLfo_i38YBg@mail.gmail.com>
Date:   Thu, 9 Apr 2020 13:56:31 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Waiman Long <longman@...hat.com>, Ingo Molnar <mingo@...nel.org>,
        Will Deacon <will@...nel.org>,
        Bernd Edlinger <bernd.edlinger@...mail.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexey Gladkov <gladkov.alexey@...il.com>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1

On Thu, Apr 9, 2020 at 1:37 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> Since they are all waiting for each other that loop is a deadlock.

No.

That's just a user bug. It's not a deadlock for the kernel.

The fact that you guys kept calling it a deadlock was what confused me
and made me think you were talking about something much more
fundamental (like the same thread trying to take the lock recursively
- *THAT* is a deadlock).

There are lots of easier ways to make people wait for each other. This
is a trivial one:

  #include <unistd.h>

  int main(void)
  {
        int fd[2];
        char buffer[1];

        pipe(fd);
        fork();
        read(fd[0], buffer, sizeof(buffer));
        write(fd[1], buffer, sizeof(buffer));
  }

where you have two readers that both wait for each other to write.

As far as the kernel is concerned, it's not a deadlock. It's just a
user space bug.

The exact same thing is true here. The user space was buggy, and set
it up so that both sides of two processes were just waiting for the
other side to do something that they never did.

And exactly like the reads, it's not a kernel bug.

Now, I do agree that from a QoI standpoint, it's annoying when
ptrace() just stops like that, particularly when you want to use
ptrace for debugging. So I'm not dismissing trying to improve on
interfaces, but I think you've confused things by calling this a
deadlock and thinking that it's a kernel bug.

The kernel never tries to figure out "Oh, stupid users are waiting for
each other". Sure, file locking has the special circular locking
detection, but that's literally a special case. The normal semantics
are that you give users rope. If users make a noose of the rope and
then trip on it, that's _their_ problem, not the kernels.

            Linus