linux-kernel - Re: [PATCH v15 5/9] erofs: introduce the page cache share feature

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: <20260119092220.GA9140@lst.de>
Date: Mon, 19 Jan 2026 10:22:20 +0100
From: Christoph Hellwig <hch@....de>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc: Christoph Hellwig <hch@....de>, Hongbo Li <lihongbo22@...wei.com>,
	chao@...nel.org, brauner@...nel.org, djwong@...nel.org,
	amir73il@...il.com, linux-fsdevel@...r.kernel.org,
	linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature

On Mon, Jan 19, 2026 at 04:52:54PM +0800, Gao Xiang wrote:
>> 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.

Sounds scary too.  But overlayfs' job is to combine underlying files, so
it is expected.  I think it's the mix of erofs being a disk based file
system, and reaching out beyond the device(s) assigned to the file system
instance that makes me feel rather uneasy.

>>
>> 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.

Right now by default we don't allow any unprivileged mounts.  Now
if people thing that say erofs is safe enough and opt into that,
it needs to be clear what the boundaries of that are.  For a file
system limited to a single block device that boundaries are
pretty clear.  For file systems reaching out to the entire system
(or some kind of domain), the scope is much wider.

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

What happens if the blob gets removed, intentionally or accidentally?

> 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.

Yes.

> 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.

And what prevents other from modifying them, or sneaking
unexpected data including unexpected comparison blobs in?