linux-kernel - Re: [PATCH v2 1/3] exec: Dynamically allocate memory to store task's full name

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: <35b4fe2a-606c-f25c-0d5c-1abb6e7b3003@igalia.com>
Date: Wed, 9 Apr 2025 17:01:05 +0530
From: Bhupesh Sharma <bhsharma@...lia.com>
To: Kees Cook <kees@...nel.org>
Cc: Bhupesh <bhupesh@...lia.com>, akpm@...ux-foundation.org,
 kernel-dev@...lia.com, linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
 linux-perf-users@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, oliver.sang@...el.com, lkp@...el.com,
 laoar.shao@...il.com, pmladek@...e.com, rostedt@...dmis.org,
 mathieu.desnoyers@...icios.com, arnaldo.melo@...il.com,
 alexei.starovoitov@...il.com, andrii.nakryiko@...il.com,
 mirq-linux@...e.qmqm.pl, peterz@...radead.org, willy@...radead.org,
 david@...hat.com, viro@...iv.linux.org.uk, ebiederm@...ssion.com,
 brauner@...nel.org, jack@...e.cz, mingo@...hat.com, juri.lelli@...hat.com,
 bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com
Subject: Re: [PATCH v2 1/3] exec: Dynamically allocate memory to store task's
 full name

Hi Kees,

Sorry for the delay - I was out for a couple of days.

On 4/4/25 10:54 PM, Kees Cook wrote:
> On Fri, Apr 04, 2025 at 12:18:56PM +0530, Bhupesh Sharma wrote:
>> In another review for this series, Yafang mentioned the following cleanup +
>> approach suggested by Linus (see [0]).
>> Also I have summarized my understanding on the basis of the suggestions
>> Linus shared and the accompanying background threads (please see [1]).
>>
>> Kindly share your views on the same, so that I can change the implementation
>> in v3 series accordingly.
> In thinking about this a little more I think we can't universally change
> all the APIs to use the new full_name since it is a pointer, which may
> be getting changed out from under readers if a setter changes it. So
> this may need some careful redesign, likely with RCU. hmm.
>

Thinking more about this, Linus mentioned in [0]:

'Since user space can randomly change their names anyway, using locking
was always wrong for readers (for writers it probably does make sense
to have some lock'

So, if we go with the union approach, probably we can do with just a writer-lock, whereas if we go with a task->full_name like pointer one, we would probably need a rcu lock.

Please let me know your comments.

[0]. https://lore.kernel.org/all/CAHk-=wivfrF0_zvf+oj6==Sh=-npJooP8chLPEfaFV0oNYTTBA@mail.gmail.com/