On Thu, Mar 27, 2025 at 4:28 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 25 Mar 2025 at 13:16, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Thu, Feb 20, 2025 at 12:48 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > On Thu, 20 Feb 2025 at 12:39, Giuseppe Scrivano <gscrivan@xxxxxxxxxx> wrote: > > > > > > > > Miklos Szeredi <miklos@xxxxxxxxxx> writes: > > > > > > > > > On Thu, 20 Feb 2025 at 10:54, Giuseppe Scrivano <gscrivan@xxxxxxxxxx> wrote: > > > > >> > > > > >> Miklos Szeredi <miklos@xxxxxxxxxx> writes: > > > > >> > > > > >> > On Tue, 11 Feb 2025 at 16:52, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > > > > > >> >> The short version - for lazy data lookup we store the lowerdata > > > > >> >> redirect absolute path in the ovl entry stack, but we do not store > > > > >> >> the verity digest, we just store OVL_HAS_DIGEST inode flag if there > > > > >> >> is a digest in metacopy xattr. > > > > >> >> > > > > >> >> If we store the digest from lookup time in ovl entry stack, your changes > > > > >> >> may be easier. > > > > >> > > > > > >> > Sorry, I can't wrap my head around this issue. Cc-ing Giuseppe. > > > > > > > > > > Giuseppe, can you describe what should happen when verity is enabled > > > > > and a file on a composefs setup is copied up? > > > > > > > > we don't care much about this case since the composefs metadata is in > > > > the EROFS file system. Once copied up it is fine to discard this > > > > information. Adding Alex to the discussion as he might have a different > > > > opinion/use case in mind. > > > > > > Okay. > > > > > > Amir, do I understand correctly that your worry is that after copy-up > > > verity digest is still being used? If that's the case, we just need > > > to make sure that OVL_HAS_DIGEST is cleared on copy-up? > > > > > > Or am I still misunderstanding this completely? > > > > Sorry, I have somehow missed this email. > > > > TBH, I am not sure what is expected to happen in the use case in question > > on copy up - that is if a full copy up on any metadata change is acceptable. > > > > Technically, we could allow a metacopy upper as long as we take the md5digest > > from the middle layer but that complicates things and I am not sure if we need > > to care - can't wrap my head around this case either. > > I've been thinking. If a lower file has verity enabled, and it is > meta-copied up on ovl with verity=on (or verity=require), then it will > have the digest stored in the .overlay.metacopy xattr. What this > ensures is that the lower file cannot be swapped out without ovl > noticing. Do you mean the lowerdata file? > However the .overlay.origin xattr ensures the same thing, origin xattr only checks from upper to uppermost lower layer IIRC, do definitely not all the way to lowerdata inode. > so as long as the user is unable to change the origin integrity should > be guaranteed. IOW, what we need is just to always check origin on > metacopy regardless of the index option. > > But I'm not even sure this is used at all, since the verity code was > added for the composefs use case, which does not use this path AFAICS. > Alex, can you clarify? I am not sure how composefs lowerdata layer is being deployed, but but I am pretty sure that the composefs erofs layers are designed to be migratable to any fs where the lowerdata repo exists, so I think hard coding the lowerdata inode is undesired. But probably I did not understand what you meant? Thanks, Amir.
