linux-kernel - Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

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: <20260115062944.GA9590@lst.de>
Date: Thu, 15 Jan 2026 07:29:44 +0100
From: Christoph Hellwig <hch@....de>
To: André Almeida <andrealmeid@...lia.com>
Cc: Christoph Hellwig <hch@....de>, Chuck Lever <chuck.lever@...cle.com>,
	Jeff Layton <jlayton@...nel.org>, NeilBrown <neil@...wn.name>,
	Olga Kornievskaia <okorniev@...hat.com>,
	Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
	Carlos Maiolino <cem@...nel.org>,
	Amir Goldstein <amir73il@...il.com>, Chris Mason <clm@...com>,
	David Sterba <dsterba@...e.com>, Miklos Szeredi <miklos@...redi.hu>,
	Christian Brauner <brauner@...nel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-btrfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
	kernel-dev@...lia.com
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

On Wed, Jan 14, 2026 at 01:17:15PM -0300, André Almeida wrote:
> Em 14/01/2026 03:26, Christoph Hellwig escreveu:
>> On Wed, Jan 14, 2026 at 01:31:43AM -0300, André Almeida wrote:
>>> Some filesystem, like btrfs, supports mounting cloned images, but assign
>>> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
>>> check, given that every time the same image is mounted, it get's
>>> assigned a new UUID.
>>
>> ... and the fix is to not assign random uuid, but to assign a new uuid
>> to the cloned image that is persisted.  That might need a new field
>> to distintguish the stamped into the format uuid from the visible
>> uuid like the xfs metauuid, but not hacks like this.
>>
>
> How can I create this non random and persisting UUID? I was thinking of 
> doing some operation on top the original UUID, like a circular shift, some 
> sort of rearrangement of the original value that we can always reproduce. 
> Is this in the right direction do you think?

Just allocate an entirely new uuid?  That's what XFS did with the
metadata uuid (persistent and stapted into all metadata headers) vs
user visible uuid that can be changed.