[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