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: <aaf98238-e8f6-472d-bfb9-7f8ddbab8e02@gmail.com>
Date: Wed, 19 Nov 2025 20:10:19 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>,
 "Darrick J. Wong" <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

On 11/19/25 16:00, Gao Xiang wrote:
> 
> 
> On 2025/11/20 02:04, Darrick J. Wong wrote:
>> On Wed, Nov 19, 2025 at 04:19:36AM -0500, Demi Marie Obenour wrote:
>>>> 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.
>>
>> Not on its own, no.
>>
>>> 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.
>>
>> I think this is easily doable for fscrypt and compression since (IIRC)
>> the kernel filesystems already know how to transform data for I/O, and
>> nowadays iomap allows hooking of bios before submission and/or after
>> endio.  Obviously you'd have to store encryption keys in the kernel
>> somewhere.
> 
> I think it depends, since (this way) it tries to reuse some of the
> existing kernel filesystem implementations (and assuming the code is
> safe), so at least it still needs to load a dedicated kernel module
> for such usage at least.

My hope is that these modules could be generic library code.
Compression, checksumming, and encryption algorithms aren't specific
to any particular filesystem, and the kernel might well be using them
already for other purposes.

Of course, it's still the host admin's job to make sure the relevant
modules are loaded, unless they are autoloaded.

> I think it's not an issue for userspace ext4 of course (because ext4
> and fscrypt is almost builtin for all kernels), but for out-of-tree
> fses even pure userspace fses, I'm not sure it's doable to load the
> module in a container context.
> 
> Maybe eBPF is useful for this area, but it's still not quite
> flexible compared to native kernel filesystems.
> 
> Thanks,
> Gao Xiang
Thank you for the feedback!
-- 
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)