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: <1be4cb25-50e2-46fa-ba86-d6342e997e63@linux.alibaba.com>
Date: Thu, 20 Nov 2025 05:51:07 +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 05: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.
> 
> 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.

Two examples for reference:

  - For compression, in-tree f2fs already has a compression header
    in data of each compressed extent:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/f2fs/f2fs.h?h=v6.17#n1497

    while other fs may store additional metadata in extent metadata
    or other place.

  - gocryptfs (a pure userspace FUSE fs) uses a different format
    from fscrypt (encrypted data seems even unaligned on disk):
    https://github.com/rfjakob/gocryptfs/blob/master/Documentation/file-format.md

> 
> Maybe eBPF is useful for this area, but it's still not quite
> flexible compared to native kernel filesystems.
> 
> Thanks,
> Gao Xiang