linux-kernel - Re: [PATCH 1/2] clone3: add CLONE3_CLEAR

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: <b3fce4a4-10a8-befe-a438-f16dfa0cdb6b@gmail.com>
Date:   Sat, 12 Oct 2019 13:46:54 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     mtk.manpages@...il.com, Aleksa Sarai <cyphar@...har.com>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Shuah Khan <shuah@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Roman Gushchin <guro@...com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Dmitry V. Levin" <ldv@...linux.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 1/2] clone3: add CLONE3_CLEAR_SIGHAND

On 10/12/19 9:48 AM, Christian Brauner wrote:
> On Sat, Oct 12, 2019 at 08:53:34AM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello Aleksa,
>>
>> On Sat, 12 Oct 2019 at 00:12, Aleksa Sarai <cyphar@...har.com> wrote:
>>>
>>> On 2019-10-11, Michael Kerrisk <mtk.manpages@...il.com> wrote:
>>>> Why CLONE3_CLEAR_SIGHAND rather than just CLONE_CLEAR_SIGHAND?
> 
> I don't care much how we name this apart from the "_CLEAR_SIGHAND"
> suffix. But see for a little rationale below.
> 
>>>
>>> There are no more flag bits left for the classic clone()/clone2() (the
>>> last one was used up by CLONE_PIDFD) -- thus this flag is clone3()-only.
>>
>> Yes, I understand that. But, I'm not sure that the "3" in the prefix
>> is necessary. "CLONE_" still seems better to me.
>>
>> Consider this: sometime in the near future we will probably have time
>> namespaces. The new flag for those namespaces will only be usable with
>> clone3(). It should NOT be called CLONE3_NEWTIME, but rather
>> CLONE_NEWTIME (or similar), because that same flag will presumably
>> also be used in other APIs such as unshare() and setns(). (Hmm -- I
> 
> There are some noteable differences though. CLONE_NEWTIME takes the
> CSIGNAL bit which is in the range of a 32bit integer and thus useable by
> unshare() too. The same does not hold for CLONE{3}_CLEAR_SIGHAND. You
> can't pass it to unshare(). unshare() also just deals with
> namespace-relevant stuff so CLONE{3}_CLEAR_SIGHAND doesn't make much
> sense there.

Sure, but going forward there's very likely to be more CLONE flags
for whatever reason, and some will be usable just in clone3()
while others will be more widely used (in other APIs such as
unshare() and setns()). Using two different prefixes for these
flags (CLONE_/CLONE3_) would be just confusing. AFAICS, the CLONE3_
prefix really provides no advantage, but does have the potential to
cause confusion down the track for the aforementioned reasons.
(Furthermore... Shudder! What if there's a clone4() one day. I
know you might say: "won't happen, we got things right this time",
but API history suggests that "right" now not infrequently becomes
"oops" later.) I do recommend CLONE_ for all the flags...

>> wonder if we are going to need a new unshare2() or some such...)
> 
> We still have one 32bit bit left (CLONE_DETACHED) which we can't reuse
> with clone()/clone2() but we can reuse with clone3(). We can simply
> earmark it for namespace-related stuff and thus still have one bit left
> for unshare() before we have to go for unshare2() (If we have to go
> there at all since I'm not sure how much more namespaces we can come up
> with.).

I'm sure there'll be more namespaces...

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/