Re: [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems

On Tue, Feb 17, 2026 at 10:18:39AM -0500, Jeff Layton wrote:
> On Tue, 2026-02-17 at 09:21 -0500, Chuck Lever wrote:
> > 
> > On Mon, Feb 16, 2026, at 11:14 PM, Shyam Prasad N wrote:
> > > On Sat, Feb 14, 2026 at 9:10 PM Chuck Lever <[email protected]> wrote:
> > > > 
> > > > 
> > > > On Sat, Feb 14, 2026, at 5:06 AM, Shyam Prasad N wrote:
> > > > > Kernel filesystems sometimes need to upcall to userspace to get some
> > > > > work done, which cannot be achieved in kernel code (or rather it is
> > > > > better to be done in userspace). Some examples are DNS resolutions,
> > > > > user authentication, ID mapping etc.
> > > > > 
> > > > > Filesystems like SMB and NFS clients use the kernel keys subsystem for
> > > > > some of these, which has an upcall facility that can exec a binary in
> > > > > userspace. However, this upcall mechanism is not namespace aware and
> > > > > upcalls to the host namespaces (namespaces of the init process).
> > > > 
> > > > Hello Shyam, we've been introducing netlink control interfaces, which
> > > > are namespace-aware. The kernel TLS handshake mechanism now uses
> > > > this approach, as does the new NFSD netlink protocol.
> > > > 
> > > > 
> > > > --
> > > > Chuck Lever
> > > 
> > > Hi Chuck,
> > > 
> > > Interesting. Let me explore this a bit more.
> > > I'm assuming that this is the file that I should be looking into:
> > > fs/nfsd/nfsctl.c
> > 
> > Yes, clustered towards the end of the file. NFSD's use of netlink
> > is as a downcall-style administrative control plane.
> > 
> > net/handshake/netlink.c uses netlink as an upcall for driving
> > kernel-initiated TLS handshake requests up to a user daemon. This
> > mechanism has been adopted by NFSD, the NFS client, and the NVMe
> > over TCP drivers. An in-kernel QUIC implementation is planned and
> > will also be using this.
> > 
> > 
> > > And that there would be a corresponding handler in nfs-utils?
> > 
> > For NFSD, nfs-utils has a new tool called nfsdctl.
> > 
> > The TLS handshake user space components are in ktls-utils. See:
> > https://github.com/oracle/ktls-utils
> 
> 
> I think the consensus at this point is to move away from usermodehelper
> as an upcall mechanism. The Linux kernel lacks a container object that
> allows you to associate namespaces with one another, so you need an
> already-running userspace process to do that association in userland.
> 
> netlink upcalls are bound to a network namespace. That works in the
> above examples because they are also bound to a network namespace.
> netlink upcalls require a running daemon in that namespace, which is
> what ties that network namespace to other sorts of namespaces.
> 
> So, a related discussion we should have is whether and how we should
> deprecate the old usermodehelper upcalls, given that they are
> problematic in this way. 

Yes, I want usermodehelpers to eventually go away with the very few
legitimate cases being ideally replaced by user workers I added a few
years ago. User workers are spawned by the kernel but are actual
children of the caller and inherit its settings just like a fork()
would.

They're not just problematic because they're namespace unaware. That's
even something we could fix, I'm sure. It's that they run with full
kernel privileges. As evidenced by the old coredump usermodehelper this
is just an invitation for security issues. It's also completely opaque
to userspace when a process suddenly pops into the process table that is
not a child and more or less out of its control that then executes
binaries placed in some location in userspace. The mechanism just
doesn't cut it anymore imho.

There's a couple of avenues we have here to redo this so having that
discussion might be useful.