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] [day] [month] [year] [list]
Message-ID: <05c37282-715e-4334-82e6-aea3241f15eb@igalia.com>
Date: Thu, 5 Feb 2026 17:34:42 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Amir Goldstein <amir73il@...il.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>,
 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,
 Qu Wenruo <wqu@...e.com>, linux-btrfs@...r.kernel.org,
 linux-unionfs@...r.kernel.org, kernel-dev@...lia.com, vivek@...labora.com,
 Ludovico de Nittis <ludovico.denittis@...labora.com>
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

Em 28/01/2026 08:49, Amir Goldstein escreveu:
> On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@...il.com> wrote:
>>
>> On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@...lia.com> wrote:
>>>
>>> Em 23/01/2026 10:24, André Almeida escreveu:
>>>>
>>>> Em 22/01/2026 17:07, Amir Goldstein escreveu:
>>>>> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@...il.com>
>>>>> wrote:
>>>>>>
>>>>>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
>>>>>> <andrealmeid@...lia.com> wrote:
>>>>>>>
>>>>> ...
>>>>>>> Actually they are not in the same fs, upper and lower are coming from
>>>>>>> different fs', so when trying to mount I get the fallback to
>>>>>>> `uuid=null`. A quick hack circumventing this check makes the mount
>>>>>>> work.
>>>>>>>
>>>>>>> If you think this is the best way to solve this issue (rather than
>>>>>>> following the VFS helper path for instance),
>>>>>>
>>>>>> That's up to you if you want to solve the "all lower layers on same fs"
>>>>>> or want to also allow lower layers on different fs.
>>>>>> The former could be solved by relaxing the ovl rules.
>>>>>>
>>>>>>> please let me know how can
>>>>>>> I safely lift this restriction, like maybe adding a new flag for this?
>>>>>>
>>>>>> I think the attached patch should work for you and should not
>>>>>> break anything.
>>>>>>
>>>>>> It's only sanity tested and will need to write tests to verify it.
>>>>>>
>>>>>
>>>>> Andre,
>>>>>
>>>>> I tested the patch and it looks good on my side.
>>>>> If you want me to queue this patch for 7.0,
>>>>> please let me know if it addresses your use case.
>>>>>
>>>>
>>>> Hi Amir,
>>>>
>>>> I'm still testing it to make sure it works my case, I will return to you
>>>> ASAP. Thanks for the help!
>>>>
>>>
>>> So, your patch wasn't initially working in my setup here, and after some
>>> debugging it turns out that on ovl_verify_fh() *fh would have a NULL
>>> UUID, but *ofh would have a valid UUID, so the compare would then fail.
>>>
>>> Adding this line at ovl_get_fh() fixed the issue for me and made the
>>> patch work as I was expecting:
>>>
>>> +       if (!ovl_origin_uuid(ofs))
>>> +               fh->fb.uuid = uuid_null;
>>> +
>>>           return fh;
>>>
>>> Please let me know if that makes sense to you.
>>
>> It does not make sense to me.
>> I think you may be using the uuid=off feature in the wrong way.
>> What you did was to change the stored UUID, but this NOT the
>> purpose of uuid=off.
>>
>> The purpose of uuid=off is NOT to allow mounting an overlayfs
>> that was previously using a different lower UUID.
>> The purpose is to mount overlayfs the from the FIRST time with
>> uuid=off so that ovl_verify_origin_fh() gets null uuid from the
>> first call that sets the ORIGIN xattr.
>>
>> IOW, if user want to be able to change underlying later UUID
>> user needs to declare from the first overlayfs mount that this
>> is expected to happen, otherwise, overlayfs will assume that
>> an unintentional wrong configuration was used.
>>
>> I updated the documentation to try to explain this better:
>>
>> Is my understanding of the problems you had correct?
>> Is my solution understood and applicable to your use case?
>>
> 
> Hi Andre,
> 
> Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
> I would need your feedback soon.
> 

Hey Amir, sorry for my delay. I just had a week out of the office and 
just got back to this.

Our initial test case worked great! We managed to mount both images and 
use overlayfs without a problem after your clarification of where to use 
uuid=off, which should be on the first mount.

However, when rebooting to the other partition, the mount failed with 
"failed to verify upper root origin" again, but I believe that I forgot 
to add `uuid=off` somewhere in the mount scripts. I'm still debugging this.

Anyhow, I see that we are now too close to the merge window, and from my 
side we can delay this for 7.1 and merge it when it gets 100% clear that 
this is the solution that we are looking for.

Thanks again for your help!
	André

> FWIW, I think that this change of restrictions for uuid=null could be backported
> to stable kernels, but I am not going to mark it for auto select, because
> I'd rather see if anyone shouts with upstream kernel first when (if) we make
> this change and manually backport later per demand.
> 
> Thanks,
> Amir.