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: <aYMkdwic6UNwTi5D@google.com>
Date: Wed, 4 Feb 2026 10:50:31 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: jongan.kim@....com
Cc: gary@...yguo.net, 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, 
	gregkh@...uxfoundation.org, heesu0025.kim@....com, ht.hong@....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 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.

> 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*.

> 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.

Alice