On Wed, Jun 14, 2023 at 09:57:41AM +0200, Alexander Larsson wrote: > When a layer containing verity xattrs is used, it means that any > such metacopy file in the upper layer is guaranteed to match the > content that was in the lower at the time of the copy-up. If at any time > (during a mount, after a remount, etc) such a file in the lower is > replaced or modified in any way, then opening the corresponding file on > overlayfs will result in EIO and a detailed error printed to the kernel logs. > (Actually, due to caching the overlayfs mount might still see the previous > file contents after a lower file is replaced under an active mount, but > it will never see the wrong data.) Well, the key point of fsverity is that data is not verified until it is actually read. At open time, the fsverity file digest is made available in constant time, and overlayfs will verify that. However, invalid data blocks are not reported until the data is actually read. The error that applications get is EIO for syscalls, and SIGBUS for memory-mapped reads, as mentioned at https://www.kernel.org/doc/html/latest/filesystems/fsverity.html#accessing-verity-files So overlayfs might report EIO at open time, or it might not report an error until the modified data is read. And in the latter case, presumably the error seen by the application matches the one for using fsverity natively? You can link to the fsverity documentation somewhere if it would be helpful, but I'd still like the semantics of how this works on overlayfs to be documented. - Eric
