linux-kernel - Re: [PATCH v3 3/3] rust_binder: handle PID namespace conversion for freeze operation

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: <20260205050128.17532-1-jongan.kim@lge.com>
Date: Thu,  5 Feb 2026 14:01:28 +0900
From: jongan.kim@....com
To: aliceryhl@...gle.com
Cc: a.hindborg@...nel.org,
	arve@...roid.com,
	bjorn3_gh@...tonmail.com,
	boqun.feng@...il.com,
	brauner@...nel.org,
	cmllamas@...gle.com,
	dakr@...nel.org,
	daniel.almeida@...labora.com,
	gary@...yguo.net,
	gregkh@...uxfoundation.org,
	heesu0025.kim@....com,
	ht.hong@....com,
	jongan.kim@....com,
	jungsu.hwang@....com,
	kernel-team@...roid.com,
	linux-kernel@...r.kernel.org,
	lossin@...nel.org,
	ojeda@...nel.org,
	rust-for-linux@...r.kernel.org,
	sanghun.lee@....com,
	seulgi.lee@....com,
	sunghoon.kim@....com,
	tamird@...il.com,
	tkjos@...roid.com,
	tmgross@...ch.edu,
	viresh.kumar@...aro.org,
	vitaly.wool@...sulko.se,
	yury.norov@...il.com
Subject: Re: [PATCH v3 3/3] rust_binder: handle PID namespace conversion for freeze operation

On Wed, Feb 04 2026 10:50:31AM +0000, Alice Ryhl wrote:
> On Wed, Feb 04, 2026 at 06:11:47PM +0900, jongan.kim@....com wrote:
> > On Tue Feb 3, 2026 at 12:59:45PM +0000, Gary Guo wrote:
> > > On Tue Feb 3, 2026 at 6:59 AM GMT, jongan.kim wrote:
> > > I think this function already has `ARef<Task>` for all the process, so it feels
> > > to me that the search should be simply based on task, rather than PID.
> > >
> > > I.e. instead of pid_t -> struct pid -> struct tasks -> pid_t and then search
> > > with it, we first get `Task` from VPID, and then search directly with it. This
> > > would also make it no longer necessary to have the init namespace check.
> > >
> > > (BTW, the current impl looks quite inefficient, get_procs_with_pid returns a vec
> > > which is pushed again to a vec, perhaps using a callback or simply passing in a
> > > `&mut Vec` is better?)
> > >
> > > Best,
> > > Gary
> > >
> > > >              procs.push(proc, GFP_KERNEL)?;
> > > >          }
> > > >      }
> >
> > Thank you for the suggestions for more efficient structure.
> >
> > Your proposal to use task-based search instead of PID-based search
> > could simplify the logic.
> >
> > However, I have a few considerations:
> > 1. The current implementation maintains consistency with the existing
> > C binder implementation. Any structural change here would ideally be
> > reflected in the  C code as well to keep both implementations aligned.
> 
> Yes, the drivers should match.
> 
> > 2. Since the majority of binder usage occurs in the init namespace, the
> > current early return (checking task_is_in_init_pid_ns) avoids the overhead
> > of find_vpid() and pid_task() calls in the common case. If we always go
> > through the task lookup path, this optimization would be lost.
> 
> Well, I suggested this approach too on the previous version:
> https://lore.kernel.org/lkml/20260130015427.83556-1-jongan.kim@lge.com/
> (I mentioned it on C Binder, but they should of course match.)
> 
> I'm not necessarily that concerned about the optimization. Freezing is
> already a bit expensive to begin with.

Sorry, I misunderstood your intention before. I will update the new patch
to apply your recommendations for both the Rust and C. Thank you for the
review and suggestions.

> > 3. Regarding the search mechanism and vec efficiency improvements you
> > mentioned, these seem like valuable optimizations but would represent
> > a broader architectural change to the binder driver.
> 
> Improving get_procs_with_pid() seems like a separate thing. Perhaps it
> could be part of this other series:
> https://lore.kernel.org/all/20260201000817.275382-1-shivamklr@cock.li/
> 
> Improving it here should only happen if you need to rewrite said
> function *anyway*.

Since we're changing the implementation to use task-based comparison instead
of PID-based comparison, we won't be using get_procs_with_pid() anymore and
will need to write a new function (e.g., get_procs_with_task()).

Would this approach align with the Rust binder development direction?

> > I'd like to get input from the binder driver maintainers on whether:
> > - This kind of structural change is desired for the binder driver
> > - If so, whether it should be done as part of this PID namespace fix or
> > as a separate refactoring effort
> 
> See above.
> 
> > - Whether both C and Rust implementations should be updated together
> >
> > Alice, could you please advise on the preferred approach here?
> 
> Both implementations should be updated together.

We will update both the Rust and C implementations together.

Thanks.
Jong An, Kim.