linux-kernel - Re: [PATCH linux-next] kernel/fork.c: annotate data races for copy

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] [day] [month] [year] [list]

Message-ID: <9b8346c8-c3b8-b0bd-b925-9545aa3482f9@huawei.com>
Date:   Wed, 17 Jun 2020 17:19:35 +0800
From:   Zefan Li <lizefan@...wei.com>
To:     Chenweilong <chenweilong@...wei.com>,
        Christian Brauner <christian.brauner@...ntu.com>
CC:     "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dvyukov@...gle.com" <dvyukov@...gle.com>
Subject: Re: [PATCH linux-next] kernel/fork.c: annotate data races for
 copy_process

On 2020/6/17 17:08, Chenweilong wrote:
>> On Tue, Jun 09, 2020 at 11:08:01AM +0800, Weilong Chen wrote:
>>> The check is only there to stop root fork bombs.
>>>
>>> BUG: KCSAN: data-race in copy_process / copy_process
>>>
>>> write to 0xffffffff86f87d20 of 4 bytes by task 7121 on cpu 5:
>>>  copy_process+0x2e1a/0x3af0 kernel/fork.c:2285
>>>  _do_fork+0xf7/0x790 kernel/fork.c:2430
>>>  __do_sys_clone+0xf9/0x130 kernel/fork.c:2585  __se_sys_clone
>>> kernel/fork.c:2566 [inline]
>>>  __x64_sys_clone+0x6c/0x80 kernel/fork.c:2566
>>>  do_syscall_64+0xc7/0x3b0 arch/x86/entry/common.c:295
>>>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>
>>> read to 0xffffffff86f87d20 of 4 bytes by task 7125 on cpu 3:
>>>  copy_process+0x9eb/0x3af0 kernel/fork.c:1967
>>>  _do_fork+0xf7/0x790 kernel/fork.c:2430
>>>  __do_sys_clone+0xf9/0x130 kernel/fork.c:2585  __se_sys_clone
>>> kernel/fork.c:2566 [inline]
>>>  __x64_sys_clone+0x6c/0x80 kernel/fork.c:2566
>>>  do_syscall_64+0xc7/0x3b0 arch/x86/entry/common.c:295
>>>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>
>>> Signed-off-by: Weilong Chen <chenweilong@...wei.com>
>>
>> Plumbing data_race() in there just to taper over this seems ugly.
>> Before we do that we should probably simply make nr_threads atomic_t.
> Will using atomic_t cause performance degradation ? I don’t know why atomic was not used in the beginning.
> 
>> Also, where's the link to the syzbot/kcsan report? Or did you get this report from somewhere else?
> I got this from local test.

There is a comment just above the if statement to explain this race:

        /*
         * If multiple threads are within copy_process(), then this check
         * triggers too late. This doesn't hurt, the check is only there
         * to stop root fork bombs.
         */

This race won't go away by making nr_threads atomic, because I think it is
tasklist_lock that protects nr_thread.

Adding data_race() here I think makes the code more readable, as a supplementary
to the code comment.