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  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:   Tue, 30 Apr 2019 09:24:06 -0700
From:   Linus Torvalds <>
To:     Oleg Nesterov <>
Cc:     Jann Horn <>, Kevin Easton <>,
        Andy Lutomirski <>,
        Christian Brauner <>,
        Aleksa Sarai <>,
        "Enrico Weigelt, metux IT consult" <>,
        Al Viro <>,
        David Howells <>,
        Linux API <>,
        LKML <>,
        "Serge E. Hallyn" <>,
        Arnd Bergmann <>,
        "Eric W. Biederman" <>,
        Kees Cook <>,
        Thomas Gleixner <>,
        Michael Kerrisk <>,
        Andrew Morton <>,
        Joel Fernandes <>,
        Daniel Colascione <>
Subject: Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

On Tue, Apr 30, 2019 at 5:39 AM Oleg Nesterov <> wrote:
> Yes, but I am wondering if man vfork should clarify what "child terminates"
> actually means. I mean, the child can do clone(CLONE_THREAD) + sys_exit(),
> this will wake the parent thread up before the child process exits or execs.

That falls solidly into the "give people rope" category.

If the vfork() child wants to mess with the parent, it has many easier
ways to do it than create more threads.

As mentioned, the real problem with vfork() tends to be that the child
unintentionally messes with the parent because it just gets the stack
sharing wrong. No need to add intention there.

> I see nothing wrong, but I was always curious whether it was designed this
> way on purpose or not.

Oh, it's definitely on purpose. Trying to do some nested usage count
would be horrendously complex, and even a trivial "don't allow any
other clone() calls if we already have a vfork completion pending" is
just unnecessary logic.

Because at least in *theory*, there's actually nothing horribly wrong
with allowing a thread to be created during the vfork(). I don't see
the _point_, but it's not conceptually something that couldn't work
(you'd need a separate thread stack etc, but that's normal clone()).

So no, there's no safety or bogus "you can't do that". If you want to
play games after vfork(), go wild.


Powered by blists - more mailing lists