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: <2f6ff2a6-6099-42da-84f0-d7adc69850b3@linux.alibaba.com>
Date: Wed, 19 Nov 2025 17:41:19 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Demi Marie Obenour <demiobenour@...il.com>, 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 2025/11/19 17:19, 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.
> 
> 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

I don't think it's generally feasible unless it's limited to
specific implementations because each transformation-like ondisk
encoded data has its own design, which is unlike raw data.

Although the algorithms are well-known but the ondisk data could
be wrapped up with headers, footers, or specific markers.

I think for the specific fscrypt or fsverity it could be possible
(for example, I'm not sure zfs is 100%-compatible with fscrypt or
fsverity, if they implements similiar stuffs), but considering
generic compression, checksumming, and encryption, filesystem
implementations can do various ways (even in various orders) with
possible additional representations.

>     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.
Thanks,
Gao Xiang