Re: [PATCHBLIZZARD v7] fuse/libfuse/e2fsprogs: containerize ext4 for safer operation

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3067 bytes --]

On 3/16/26 19:08, Joanne Koong wrote:
> On Mon, Mar 16, 2026 at 11:04 AM Darrick J. Wong <djwong@kernel.org> wrote:
>>
>> On Mon, Mar 16, 2026 at 10:56:21AM -0700, Joanne Koong wrote:
>>> On Mon, Feb 23, 2026 at 2:46 PM Darrick J. Wong <djwong@kernel.org> wrote:
>>>>
>>>> There are some warts remaining:
>>>>
>>>> a. I would like to continue the discussion about how the design review
>>>>    of this code should be structured, and how might I go about creating
>>>>    new userspace filesystem servers -- lightweight new ones based off
>>>>    the existing userspace tools?  Or by merging lklfuse?
>>>
>>> What do you mean by "merging lklfuse"?
>>
>> Merging the lklfuse project into upstream Linux, which involves running
>> the whole kit and caboodle through our review process, and then fixing
> 
> Gotcha, so it would basically be having to port this arch/lkl
> directory [1] into the linux tree
> 
>> user-mode-linux to work anywhere other than x86.
> 
> Are lklfuse and user-mode-linux (UML) two separate things or is
> lklfuse dependent on user-mode-linux?
> 
>>
>>> Could you explain what the limitations of lklfuse are compared to the
>>> fuse iomap approach in this patchset?
>>
>> The ones I know about are:
>>
>> 1> There's no support for vmapped kernel memory in UML mode, so anyone
>> who requires a large contiguous memory buffer cannot assemble them out
>> of "physical" pages.  This has been a stumbling block for XFS in the
>> past.
>>
>> 2> LKLFUSE still uses the classic fuse IO paths, which means that at
>> best you can directio the IO through the lklfuse kernel.  At worst you
>> have to use the pagecache inside the lklfuse kernel, which is very
>> wasteful.
> 
> For the security / isolation use cases you've described, is
> near-native performance a hard requirement?

It should be good enough that distros are willing to use it by default.
Otherwise, there is no way to break out of the loop where kernel devs
say to not mount untrusted filesystems, yet the distros keep doing
that because people have stuff they need to get done.

I know from talking to Neal Gompa that libguestfs is too slow for this.

> As I understand it, the
> main use cases of this will be for mounting untrusted disk images and
> CI/filesystem testing, or are there broader use cases beyond this?

Anyone with strong verified boot requirements is going to want this.
The threat model used by Android and Chromium OS is that all on-disk
state is *never* trusted.  The root filesystem is on a dm-verity
protected partition, so mounting it in the kernel is fine.  However,
the writable partition should be mounted in userspace.

I checked with the ChromeOS security team, and they do consider being
able to write corrupted metadata to disk that compromises the system
on the next reboot to be a vulnerability.

This is also a case where performance actually matters, including
for F2FS on zoned UFS which is always copy-on-write for user data.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]