From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7AFC5266B67 for ; Fri, 9 Jan 2026 07:50:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767945004; cv=none; b=olGY3wHGQChcLVtzKvqwCNkaCnWGgbNy9RS5Hl8fEJ8nNMH2M5i7i2ql6ZgPA3pOfvHO/k4wc8kxl2tzvbsQtFenqZ65M3n/wUXVUlBtkzQoHs2Zl4V+Lr/Z+m6p26fq0au8LXI6YZNdX1AKn+oz9k90aFf9OJWBshTN7xRvfko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767945004; c=relaxed/simple; bh=Wlmj2Y+cyfUK8u666tmf0JbfVVm5Ddkt9DXryfwJ01c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LTXZnPT3DsxLlSngaHeIi3rcwYVe0DmUbnMA7HlXk3iViNEZaKqimr4p77TAEtlBJZhYfgdFh0/ii5NodKfeAEnHu8gipP1EsjANO0R4794c1jvqtXj+436BqfLiRKivCbViwhrh+JUNSKHl452zGGCH/N1QPBFmMBg9ymh6Oyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=XNnRe+0B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="XNnRe+0B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8225FC4CEF1; Fri, 9 Jan 2026 07:50:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1767945004; bh=Wlmj2Y+cyfUK8u666tmf0JbfVVm5Ddkt9DXryfwJ01c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XNnRe+0ByPwfnBga2XVg6I6AqBg4ZlJw7cSX4YORGuHjYplOPgL88rR1Nsi309yv1 xml9ztAph/Sql4noMotYZ8scO62+VKuJn5MQjsZQrIeuJS97iP2Rwp9smcs4Oi0C9f JBB396d3GnA+ULJRiLt18gv0gGu4R/YQv+exiTsg= Date: Fri, 9 Jan 2026 08:50:01 +0100 From: Greg KH To: jongan.kim@lge.com Cc: aliceryhl@google.com, arve@android.com, brauner@kernel.org, cmllamas@google.com, ht.hong@lge.com, jungsu.hwang@lge.com, kernel-team@android.com, linux-kernel@vger.kernel.org, sanghun.lee@lge.com, seulgi.lee@lge.com, sunghoon.kim@lge.com, tkjos@android.com Subject: Re: [PATCH RESEND] binder: handle PID namespace conversion for freeze operation Message-ID: <2026010941-carwash-disabled-c713@gregkh> References: <2026010828-squash-tranquil-7544@gregkh> <696087cf.050a0220.9a5fe.0a86SMTPIN_ADDED_BROKEN@mx.google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <696087cf.050a0220.9a5fe.0a86SMTPIN_ADDED_BROKEN@mx.google.com> On Fri, Jan 09, 2026 at 01:44:22PM +0900, jongan.kim@lge.com wrote: > From: Greg KH > > > On Thu, Jan 08, 2026 at 10:10:11AM +0900, jongan.kim@lge.com wrote: > > > From: "JongAn Kim" > > > > > > Currently, when a freeze is attempted from a non-init PID namespace, > > > there is a possibility that the wrong process in the init namespace > > > may be frozen due to PID collision across namespaces. > > > > I did not think that binder worked with pid namespaces. I think I've > > asked this before and was told it was not supported. > > > > So how are you running into this? What system requires this? > > Thank you for your feedback. > We isolated the pid namespace in order to run the legacy system within > Android Automotive. Upon contacting Google, we were informed that the > binder’s freeze operation currently does not support the pid namespace. > They also mentioned that once this binder freeze problem is resolved, > we can use pid namespace with android GKI. I don't think any of binder supports pid namespaces. Well, maybe one thread thing, but not the normal functionality from what I can see. So why just focus on the freeze ioctl? What about all of the other ones? > > > For example, if a container with PID namespace has a process with > > > PID 100 (which maps to PID 5000 in init namespace), attempting to > > > freeze PID 100 from the container could incorrectly match a different > > > process with PID 100 in the init namespace. > > > > > > This patch fixes the issue by: > > > 1. Converting the caller's PID from their namespace to init namespace > > > 2. Matching against binder_proc->pid (which stores init namespace TGID) > > > 3. Returning -EINVAL for invalid PIDs and -ESRCH for not-found processes > > > > Are you sure this is the only place pid namespaces come into play in > > binder? If this is going to be supported, I think all uses of pids need > > to handle namespaces. > > > > or am I confused as to what is broken here? > > > > thanks, > > > > greg k-h > > As far as we've confirmed, only the binder’s freeze ioctl operation receives > and processes a pid from user space. (other binder operation except freeze > handles pid as global pid in kernel space.) Are you sure? Those pids come from userspace, how can they be "global"? > Since binder_open() registers the pid to binder_procs based on the global pid > of the init namespace, the freeze operation does not function correctly when > executed within a separate namespace. Moreover, in cases where duplicate pid > exist, there is a potential risk of freezing an unintended process in the init > namespace. So you are relying on the registration in the global namespace, but what about the others? I see a lot of "raw" pids happening in the binder code, it's odd that this would only be an issue in that one ioctl. And, I hate to ask, what about the rust version of binder in the tree now? What does that do? :) thanks, greg k-h