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: <af9a8030-cd19-457c-8c15-cb63e8140dfc@linux.alibaba.com>
Date: Thu, 20 Nov 2025 05:00:38 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: "Darrick J. Wong" <djwong@...nel.org>,
 Demi Marie Obenour <demiobenour@...il.com>
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 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.

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