From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
Jann Horn <jannh@google.com>
Cc: John Ericson <mail@johnericson.me>,
linux-api@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Kees Cook <kees@kernel.org>,
Farid Zakaria <farid.m.zakaria@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org
Subject: [PATCH RFC 0/7] fs: add failfs
Date: Thu, 23 Jul 2026 13:30:19 +0200 [thread overview]
Message-ID: <20260723-work-failfs-v1-0-3f69b9a9e958@kernel.org> (raw)
nullfs provides a permanently empty and immutable directory. Lookups
fail with ENOENT. The directory can be opened, read, stat, mounted upon.
It behaves like nothing is there.
Add its counterpart failfs where the semantics are not "there is
nothing here" but "nothing is supported here". Every operation that
reaches the filesystem fails with EOPNOTSUPP. Even statfs()/fstatfs()
fail so the filesystem cannot be discovered through an fd to it.
EOPNOTSUPP rather than a permission errno keeps that coherent. There
is no permission model in which anything could ever be allowed and
EACCES or EPERM would merely suggest that different credentials might
succeed while EIO would suggest corruption. It also makes hitting the
failfs boundary mostly quite dinstinguishable. A task anchoring its
lookups at real directory file descriptors may be able to tell a failfs
refusal from an ordinary permission failure. I wouldn't go so far as
guaranteeing that but it should mostly work.
The root cannot be opened at all not even with O_PATH. It is never
reached by a lookup in a parent directory. The only way to a path-walk
terminal at the root is a jump through a /proc/<pid>/{root,cwd} magic
link or by mountpoint traversal. The root also refuses
->d_weak_revalidate() which the VFS calls for jumped terminals. That
closes every remaining way to reference it. An O_PATH
open is refused and name_to_handle_at() cannot encode it into a file
handle, and following a magic link into it fails. A plain readlink() of
such a link still works and shows "/".
There is a single instance of failfs mounted during early boot via
kern_mount() making it logically distinct from every mount namespace.
Since the mount is a member of no mount namespace mounting onto it
fails. So nothing can ever be mounted on top of it. It cannot be cloned
via OPEN_TREE_CLONE and it does not show up in statmount()/listmount()
or /proc/<pid>/mountinfo. The filesystem is not registered so it is
not visible in /proc/filesystems and cannot be mounted from userspace.
This lets tasks shed their filesystem state completely. A process with
its root directory or working directory in failfs must anchor every path
lookup at an explicit file descriptor or is doomed to fail any lookup.
Absolute paths, absolute symlinks, and AT_FDCWD-relative lookups
simply fail. Followup patches will expose it via a new FD_FAILFS_ROOT
file descriptor sentinel understood by fchdir() and the new fchroot()
system call.
Fun fact, because of how dynamic binary execution work with PT_INTERP
this also currently prevents execution of dynamic binaries because
loaders have absolute paths (see selftests).
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
Christian Brauner (7):
fs: add failfs
fs: add FD_FAILFS_ROOT and support it in fchdir()
fs: add fchroot()
fs: support FD_FAILFS_ROOT in fchroot()
arch: hookup fchroot() system call
selftests/filesystems: add failfs selftests
Documentation: add failfs documentation
Documentation/filesystems/failfs.rst | 64 +++
Documentation/filesystems/index.rst | 1 +
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/tools/syscall_32.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/Makefile | 2 +-
fs/failfs.c | 155 +++++++
fs/internal.h | 3 +
fs/namespace.c | 1 +
fs/open.c | 58 ++-
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/unistd.h | 6 +-
include/uapi/linux/fcntl.h | 1 +
include/uapi/linux/magic.h | 1 +
scripts/syscall.tbl | 1 +
tools/testing/selftests/Makefile | 1 +
.../selftests/filesystems/failfs/.gitignore | 2 +
.../testing/selftests/filesystems/failfs/Makefile | 5 +
.../selftests/filesystems/failfs/failfs_test.c | 506 +++++++++++++++++++++
32 files changed, 821 insertions(+), 3 deletions(-)
---
base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
change-id: 20260723-work-failfs-d86a0c1db48d
next reply other threads:[~2026-07-23 11:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 11:30 Christian Brauner [this message]
2026-07-23 11:30 ` [PATCH RFC 1/7] fs: add failfs Christian Brauner
2026-07-23 11:30 ` [PATCH RFC 2/7] fs: add FD_FAILFS_ROOT and support it in fchdir() Christian Brauner
2026-07-23 11:30 ` [PATCH RFC 3/7] fs: add fchroot() Christian Brauner
2026-07-23 11:30 ` [PATCH RFC 4/7] fs: support FD_FAILFS_ROOT in fchroot() Christian Brauner
2026-07-23 12:49 ` Andy Lutomirski
2026-07-23 13:01 ` Christian Brauner
2026-07-23 13:50 ` Andy Lutomirski
2026-07-23 14:35 ` Christian Brauner
2026-07-23 16:59 ` Andy Lutomirski
2026-07-23 14:42 ` Jann Horn
2026-07-23 14:07 ` Jann Horn
2026-07-23 16:56 ` Andy Lutomirski
2026-07-23 11:30 ` [PATCH RFC 5/7] arch: hookup fchroot() system call Christian Brauner
2026-07-23 11:30 ` [PATCH RFC 6/7] selftests/filesystems: add failfs selftests Christian Brauner
2026-07-23 11:30 ` [PATCH RFC 7/7] Documentation: add failfs documentation Christian Brauner
2026-07-23 14:04 ` Miquel Sabaté Solà
2026-07-23 12:53 ` [PATCH RFC 0/7] fs: add failfs Andy Lutomirski
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=20260723-work-failfs-v1-0-3f69b9a9e958@kernel.org \
--to=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=farid.m.zakaria@gmail.com \
--cc=hpa@zytor.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mail@johnericson.me \
--cc=viro@zeniv.linux.org.uk \
/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