linux-kernel - Re: [PATCH v2 2/2] pid: Remove pidhash

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: <CAOCi2DEyxPcFGRmNMsCSogSV4PLWKukkaVm8G6+9jsy5HwKxFA@mail.gmail.com>
Date:   Sat, 30 Sep 2017 21:11:56 +0530
From:   Gargi Sharma <gs051095@...il.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     linux-kernel@...r.kernel.org, Rik van Riel <riel@...riel.com>,
        Julia Lawall <julia.lawall@...6.fr>, akpm@...ux-foundation.org,
        mingo@...nel.org, pasha.tatashin@...cle.com, ktkhai@...tuozzo.com,
        Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [PATCH v2 2/2] pid: Remove pidhash

On Wed, Sep 27, 2017 at 9:58 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> If I was not clear...
>
> in short, after this patch the very first idr_alloc_cyclic() is already
> wrong. Because, once again, the new not-fully-initialized pid can be found
> by find_pid_ns().

 If the PIDNS_ADDING check fails, I jump to the flag that performs
 this
 while (++i <= ns->level)
                 idr_remove(&ns->idr, (pid->numbers + i)->nr);
 So when find_pid_ns() is called, it will not find this pid.

>
> perhaps you should chane the previous patch to do
> idr_alloc_cyclic(ptr = NULL) and use idr_replace() in this patch after
> the PIDNS_HASH_ADDING check.

I'm not sure if I understand this. Do we want to do this to make sure
the pid namespace is
initialized before the first process enters into
the namespace? If yes, how does idr_alloc_cyclic(ptr = NULL) help?

>
> And I just noticed you didn't cc Eric Biederman <ebiederm@...ssion.com>,
> please do next time.

Sorry for missing out on this. Will do with the next version.

Thanks!
Gargi
>
>
> On 09/27, Oleg Nesterov wrote:
>>
>> On 09/27, Gargi Sharma wrote:
>> >
>> > -#define find_next_offset(map, off)                                 \
>> > -           find_next_zero_bit((map)->page, BITS_PER_PAGE, off)
>> > -
>>
>> this should go into the previous patch, but this is minor...
>>
>> > @@ -208,12 +200,10 @@ struct pid *alloc_pid(struct pid_namespace *ns)
>> >
>> >     upid = pid->numbers + ns->level;
>> >     spin_lock_irq(&pidmap_lock);
>> > -   if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
>> > +   if (!(ns->pid_allocated & PIDNS_ADDING))
>> >             goto out_unlock;
>> >     for ( ; upid >= pid->numbers; --upid) {
>> > -           hlist_add_head_rcu(&upid->pid_chain,
>> > -                           &pid_hash[pid_hashfn(upid->nr, upid->ns)]);
>> > -           upid->ns->nr_hashed++;
>> > +           upid->ns->pid_allocated++;
>>
>> No, this is wrong.
>>
>> It is too late to check PIDNS_HASH_ADDING/PIDNS_ADDING and increment pid_allocated,
>> once we call idr_alloc_cyclic() this pid is already "hashed" in that it can be found
>> by find_pid_ns() with this patch applied.
>>
>> And of course, it is too late to do atomic_set(&pid->count, 1) and initialize
>> pid->tasks[type] lists by the same reason.
>>
>> Oleg.
>