From: Christian Brauner <brauner@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Chuck Lever <cel@kernel.org>,
Shyam Prasad N <nspmangalore@gmail.com>,
lsf-pc@lists.linux-foundation.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
keyrings@vger.kernel.org, CIFS <linux-cifs@vger.kernel.org>,
linux-nfs@vger.kernel.org, David Howells <dhowells@redhat.com>
Subject: Re: [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems
Date: Tue, 24 Feb 2026 09:35:25 +0100 [thread overview]
Message-ID: <20260224-luftzug-wildfremd-c15f558741e8@brauner> (raw)
In-Reply-To: <785793ea21fb65c3e721b51f24897b3000e4aec3.camel@kernel.org>
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 <cel@kernel.org> 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.
next prev parent reply other threads:[~2026-02-24 8:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 10:06 [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems Shyam Prasad N
2026-02-14 15:39 ` Chuck Lever
2026-02-17 4:14 ` Shyam Prasad N
2026-02-17 14:21 ` Chuck Lever
2026-02-17 15:18 ` Jeff Layton
2026-02-24 3:31 ` Shyam Prasad N
2026-02-24 8:35 ` Christian Brauner [this message]
2026-02-24 3:15 ` Shyam Prasad N
2026-02-16 0:48 ` David Leadbeater
2026-02-17 4:16 ` Shyam Prasad N
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260224-luftzug-wildfremd-c15f558741e8@brauner \
--to=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=dhowells@redhat.com \
--cc=jlayton@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=nspmangalore@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).