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: <1e9134c2-d984-41a3-b294-166b7e3e6bcf@linux.alibaba.com>
Date: Tue, 20 Jan 2026 22:11:11 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Christian Brauner <brauner@...nel.org>, Christoph Hellwig <hch@....de>
Cc: Hongbo Li <lihongbo22@...wei.com>, chao@...nel.org, djwong@...nel.org,
 amir73il@...il.com, linux-fsdevel@...r.kernel.org,
 linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
 Linus Torvalds <torvalds@...ux-foundation.org>, oliver.yang@...ux.alibaba.com
Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature

Hi Christian,

On 2026/1/20 21:40, Christian Brauner wrote:
> On Tue, Jan 20, 2026 at 07:52:42AM +0100, Christoph Hellwig wrote:
>> On Tue, Jan 20, 2026 at 11:07:48AM +0800, Gao Xiang wrote:
>>>
>>> Hi Christoph,
>>>
>>> Sorry I didn't phrase things clearly earlier, but I'd still
>>> like to explain the whole idea, as this feature is clearly
>>> useful for containerization. I hope we can reach agreement
>>> on the page cache sharing feature: Christian agreed on this
>>> feature (and I hope still):
>>>
>>> https://lore.kernel.org/linux-fsdevel/20260112-begreifbar-hasten-da396ac2759b@brauner
>>
>> He has to ultimatively decide.  I do have an uneasy feeling about this.
>> It's not super informed as I can keep up, and I'm not the one in charge,
>> but I hope it is helpful to share my perspective.
> 
> It always is helpful, Christoph! I appreciate your input.

Thanks, I will raise some extra comments for Hongbo
to change to make this feature more safer.

> 
> I'm fine with this feature. But as I've said in person: I still oppose
> making any block-based filesystem mountable in unprivileged containers
> without any sort of trust mechanism.

Nevertheless, since Christoph put this topic on the
community list, I had to repeat my own latest
thoughts of this on the list for reference.

Anyway, some people would just be nitpicky to the words
above as a policy: they will re-invent new
non-block-based trick filesystems (but with much odd
kernel-parsed metadata design) for the kernel community.

Honestly, my own idea is that we should find real
threats instead of arbitary assumptions against different
types of filesystems.  The original question is still
that what provents _kernel filesystems with kernel-parsed
metadata_ from mountable in unprivileged containers.

On my own perspective (in public, without any policy
involved), I think it would be better to get some fair
technical points & concerns, so that either we either fully
get in agreement as the real dead end or really overcome
some barriers since this feature is indeed useful.

I will not repeat my thoughts again to annoy folks even
further for this topic, but document here for reference.

> 
> I am however open in the future for block devices protected by dm-verity
> with the root hash signed by a sufficiently trusted key to be mountable
> in unprivileged containers.

Signed images will be a good start, I fully agree.

No one really argues that, and I believe I've told the
signed image ideas in person to Christoph and Darrick too.

Thanks,
Gao Xiang