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: <b29b112e-5fe1-414b-9912-06dcd7d7d204@linux.alibaba.com>
Date: Mon, 19 Jan 2026 16:52:54 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Christoph Hellwig <hch@....de>
Cc: 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 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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ