From: Tao Cui <cui.tao@linux.dev>
To: linux-unionfs@vger.kernel.org, miklos@szeredi.hu, amir73il@gmail.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
cui.tao@linux.dev, Tao Cui <cuitao@kylinos.cn>
Subject: [PATCH] ovl: reject verity= together with userxattr
Date: Thu, 3 Sep 2026 14:45:03 +0800 [thread overview]
Message-ID: <20260903064504.1052841-1-cui.tao@linux.dev> (raw)
From: Tao Cui <cuitao@kylinos.cn>
userxattr forces metacopy off, and copy-up only computes and stores
the verity digest for metacopy inodes. With "userxattr,verity=on"
(or verity=require) the mount succeeds, verity is advertised in
mountinfo, but no digest is ever generated and no lowerdata is ever
verified - the option silently does nothing:
$ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
(mount succeeds; after copy-up the upper inode carries only the
origin xattr, no metacopy xattr, no digest)
Follow the existing pattern for redirect_dir/metacopy and reject the
explicit combination at parse time:
$ mount -t overlay ovl -o lowerdir=$l,upperdir=$u,workdir=$w,userxattr,verity=on /mnt
mount: /mnt: wrong fs type, bad option, bad superblock...
overlayfs: conflicting options: userxattr,verity=on
This does not affect per-file fs-verity on the lower layers used
together with userxattr (e.g. fstests overlay/089): it only concerns
the verity= mount option, whose copy-up digest semantics cannot be
honored when userxattr forces metacopy off.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
fs/overlayfs/params.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
index c93fcaa45d4a..29dfc16fecc9 100644
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -997,6 +997,11 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx,
pr_err("conflicting options: userxattr,metacopy=on\n");
return -EINVAL;
}
+ if (config->verity_mode) {
+ pr_err("conflicting options: userxattr,verity=%s\n",
+ ovl_verity_mode(config));
+ return -EINVAL;
+ }
/*
* Silently disable default setting of redirect and metacopy.
* This shall be the default in the future as well: these
--
2.43.0
next reply other threads:[~2026-09-03 6:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 6:45 Tao Cui [this message]
2026-09-03 8:09 ` [PATCH] ovl: reject verity= together with userxattr Amir Goldstein
2026-09-03 9:11 ` Tao Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260903064504.1052841-1-cui.tao@linux.dev \
--to=cui.tao@linux.dev \
--cc=amir73il@gmail.com \
--cc=cuitao@kylinos.cn \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.