linux-ext4 - Re: [PATCHSET v6 4/8] fuse: allow servers to use iomap for better file IO performance

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: <d0a122b8-3b25-44e6-8c60-538c81b35228@gmail.com>
Date: Wed, 19 Nov 2025 04:19:36 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: djwong@...nel.org
Cc: bernd@...ernd.com, joannelkoong@...il.com, linux-ext4@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, miklos@...redi.hu, neal@...pa.dev,
 linux-bcachefs@...r.kernel.org, linux-btrfs@...r.kernel.org,
 zfs-devel@...t.zfsonlinux.org
Subject: Re: [PATCHSET v6 4/8] fuse: allow servers to use iomap for better
 file IO performance

> By keeping the I/O path mostly within the kernel, we can dramatically
> increase the speed of disk-based filesystems.

ZFS, BTRFS, and bcachefs all support compression, checksumming,
and RAID.  ZFS and bcachefs also support encryption, and f2fs and
ext4 support fscrypt.

Will this patchset be able to improve FUSE implementations of these
filesystems?  I'd rather not be in the situation where one can have
a FUSE filesystem that is fast, but only if it doesn't support modern
data integrity or security features.

I'm not a filesystem developer, but here are some ideas (that you
can take or leave):

1. Keep the compression, checksumming, and/or encryption in-kernel,
   and have userspace tell the kernel what algorithm and/or encryption
   key to use.  These algorithms are generally well-known and secure
   against malicious input.  It might be necessary to make an extra
   data copy, but ideally that copy could just stay within the
   CPU caches.

2. Somehow integrate with the blk-crypto framework.  This has the
   advantage that it supports inline encryption hardware, which
   I suspect is needed for this to be usable on mobile devices.
   After all, the keys on these systems are often not even visible
   to the kernel, let alone to userspace.

3. Figure out a way to make a userspace data path fast enough.
   To prevent data corruption by unprivileged users of the FS,
   it's necessary to make a copy before checksumming, compression,
   or authenticated encryption.  If this copy is done in the kernel,
   the server doesn't have to perform its own copy.  By using large
   ring buffers, it might be possible to amortize the context switch
   cost away.

   Authenticated encryption also needs a copy in the *other* direction:
   if the (untrusted) client can see unauthenticated plaintext, it's
   a security vulnerability.  That needs another copy from server
   buffers to client buffers, and the kernel can do that as well.

4. Make context switches much faster.  L4-style IPC is incredibly fast,
   at least if one doesn't have to worry about Spectre.  Unfortunately,
   nowadays one *does* need to worry about Spectre.

Obviously, none of these will be as fast as doing DMA directly to user
buffers.  However, all of these features (except for encryption using
inline encryption hardware) come at a performance penalty already.
I just don't want a FUSE server to have to pay a much larger penalty
than a kernel filesystem would.

I'm CCing the bcachefs, BTRFS, and ZFS-on-Linux mailing lists.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)