[PATCH v15 5/9] erofs: introduce the page cache share feature

Gao Xiang hsiangkao at linux.alibaba.com
Mon Jan 19 19:52:54 AEDT 2026



On 2026/1/19 16:32, Christoph Hellwig wrote:
> On Mon, Jan 19, 2026 at 03:53:21PM +0800, Gao Xiang wrote:
>> I just tried to say EROFS doesn't limit what's
>> the real meaning of `fingerprint` (they can be serialized
>> integer numbers for example defined by a specific image
>> publisher, or a specific secure hash.  Currently,
>> "mkfs.erofs" will generate sha256 for each files), but
>> left them to the image builders:
> 
> To me this sounds pretty scary, as we have code in the kernel's trust
> domain that heavily depends on arbitrary userspace policy decisions.

For example, overlayfs metacopy can also points to
arbitary files, what's the difference between them?
https://docs.kernel.org/filesystems/overlayfs.html#metadata-only-copy-up

By using metacopy, overlayfs can access arbitary files
as long as the metacopy has the pointer, so it should
be a priviledged stuff, which is similar to this feature.

> 
> Similarly the sharing of blocks between different file system
> instances opens a lot of questions about trust boundaries and life
> time rules.  I don't really have good answers, but writing up the

Could you give more details about the these? Since you
raised the questions but I have no idea what the threats
really come from.

As for the lifetime: The blob itself are immutable files,
what the lifetime rules means?

And how do you define trust boundaries?  You mean users
have no right to access the data?

I think it's similar: for blockdevice-based filesystems,
you mount the filesystem with a given source, and it
should have permission to the mounter.

For multiple-blob EROFS filesystems, you mount the
filesystem with multiple data sources, and the blockdevices
and/or backed files should have permission to the
mounters too.

I don't quite get the point.

Thanks,
Gao Xiang

> lifetime and threat models would really help.



More information about the Linux-erofs mailing list