Documentation/admin-guide/device-mapper/verity.rst | 5 +++++ drivers/md/Kconfig | 14 ++++++++++++++ drivers/md/dm-verity-verify-sig.c | 4 ++-- 3 files changed, 21 insertions(+), 2 deletions(-)
Add DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE Kconfig option. When enabled,
dm-verity always requires a valid root hash signature: require_signatures
defaults to true and can no longer be cleared on the command line. When
disabled, the existing require_signatures module parameter controls
enforcement.
Signed-off-by: Ayoub Zaki <ayoub.zaki@embetrix.com>
---
Documentation/admin-guide/device-mapper/verity.rst | 5 +++++
drivers/md/Kconfig | 14 ++++++++++++++
drivers/md/dm-verity-verify-sig.c | 4 ++--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst
index eb9475d7e196..bb48c001aeac 100644
--- a/Documentation/admin-guide/device-mapper/verity.rst
+++ b/Documentation/admin-guide/device-mapper/verity.rst
@@ -163,6 +163,11 @@ root_hash_sig_key_desc <key_description>
also gain new certificates at run time if they are signed by a certificate
already in the secondary trusted keyring.
+ Whether a signature is required for every dm-verity device is controlled by
+ the dm_verity.require_signatures parameter which defaults to off. Setting
+ DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE makes it default to on in which case it
+ can no longer be turned off.
+
try_verify_in_tasklet
If verity hashes are in cache and the IO size does not exceed the limit,
verify data blocks in bottom half instead of workqueue. This option can
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index df27c7d066d2..59098d1f4534 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -610,6 +610,20 @@ config DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING
If unsure, say N.
+config DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE
+ bool "Require dm-verity root hash signature verification"
+ depends on DM_VERITY_VERIFY_ROOTHASH_SIG
+ help
+ Reject dm-verity devices that are created without a valid root hash
+ signature. Without this, whether a signature is required is decided
+ at boot time by the dm_verity.require_signatures parameter which
+ defaults to off.
+
+ Enabling this makes that parameter default to on and it can then no
+ longer be turned off.
+
+ If unsure, say N.
+
config DM_VERITY_FEC
bool "Verity forward error correction support"
depends on DM_VERITY
diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c
index b2b55c41e2cb..aadcf5e4a47c 100644
--- a/drivers/md/dm-verity-verify-sig.c
+++ b/drivers/md/dm-verity-verify-sig.c
@@ -21,8 +21,8 @@ static bool dm_verity_keyring_unsealed __ro_after_init;
module_param_named(keyring_unsealed, dm_verity_keyring_unsealed, bool, 0444);
MODULE_PARM_DESC(keyring_unsealed, "Leave the dm-verity keyring unsealed");
-static bool require_signatures;
-module_param(require_signatures, bool, 0444);
+static bool require_signatures = IS_ENABLED(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE);
+module_param(require_signatures, bool_enable_only, 0444);
MODULE_PARM_DESC(require_signatures,
"Verify the roothash of dm-verity hash tree");
base-commit: df2908090cda368b01ff43709f51890076c56157
--
2.43.0Hi The argument can be turned off even with your patch - by specifying dm_verity.require_signatures=0 on the kernel command line (read-only module parameters can be modified on the command line during boot). I'd like to know what kind of security problem does this patch try to solve. If the attacker can tamper with the kernel command line, he can already gain root (i.e. by using init=/bin/bash). Mikulas On Mon, 7 Sep 2026, Ayoub Zaki wrote: > Add DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE Kconfig option. When enabled, > dm-verity always requires a valid root hash signature: require_signatures > defaults to true and can no longer be cleared on the command line. When > disabled, the existing require_signatures module parameter controls > enforcement. > > Signed-off-by: Ayoub Zaki <ayoub.zaki@embetrix.com> > --- > Documentation/admin-guide/device-mapper/verity.rst | 5 +++++ > drivers/md/Kconfig | 14 ++++++++++++++ > drivers/md/dm-verity-verify-sig.c | 4 ++-- > 3 files changed, 21 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst > index eb9475d7e196..bb48c001aeac 100644 > --- a/Documentation/admin-guide/device-mapper/verity.rst > +++ b/Documentation/admin-guide/device-mapper/verity.rst > @@ -163,6 +163,11 @@ root_hash_sig_key_desc <key_description> > also gain new certificates at run time if they are signed by a certificate > already in the secondary trusted keyring. > > + Whether a signature is required for every dm-verity device is controlled by > + the dm_verity.require_signatures parameter which defaults to off. Setting > + DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE makes it default to on in which case it > + can no longer be turned off. > + > try_verify_in_tasklet > If verity hashes are in cache and the IO size does not exceed the limit, > verify data blocks in bottom half instead of workqueue. This option can > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > index df27c7d066d2..59098d1f4534 100644 > --- a/drivers/md/Kconfig > +++ b/drivers/md/Kconfig > @@ -610,6 +610,20 @@ config DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING > > If unsure, say N. > > +config DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE > + bool "Require dm-verity root hash signature verification" > + depends on DM_VERITY_VERIFY_ROOTHASH_SIG > + help > + Reject dm-verity devices that are created without a valid root hash > + signature. Without this, whether a signature is required is decided > + at boot time by the dm_verity.require_signatures parameter which > + defaults to off. > + > + Enabling this makes that parameter default to on and it can then no > + longer be turned off. > + > + If unsure, say N. > + > config DM_VERITY_FEC > bool "Verity forward error correction support" > depends on DM_VERITY > diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c > index b2b55c41e2cb..aadcf5e4a47c 100644 > --- a/drivers/md/dm-verity-verify-sig.c > +++ b/drivers/md/dm-verity-verify-sig.c > @@ -21,8 +21,8 @@ static bool dm_verity_keyring_unsealed __ro_after_init; > module_param_named(keyring_unsealed, dm_verity_keyring_unsealed, bool, 0444); > MODULE_PARM_DESC(keyring_unsealed, "Leave the dm-verity keyring unsealed"); > > -static bool require_signatures; > -module_param(require_signatures, bool, 0444); > +static bool require_signatures = IS_ENABLED(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE); > +module_param(require_signatures, bool_enable_only, 0444); > MODULE_PARM_DESC(require_signatures, > "Verify the roothash of dm-verity hash tree"); > > > base-commit: df2908090cda368b01ff43709f51890076c56157 > -- > 2.43.0 >
Hi, On 9/21/26 11:46, Mikulas Patocka wrote: > Hi > > The argument can be turned off even with your patch - by specifying > dm_verity.require_signatures=0 on the kernel command line (read-only > module parameters can be modified on the command line during boot). > > I'd like to know what kind of security problem does this patch try to > solve. If the attacker can tamper with the kernel command line, he can > already gain root (i.e. by using init=/bin/bash). > > Mikulas Thanks for reviewing. I should have highlighted the change to bool_enable_only: with CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE=y it rejects attempts to clear require_signatures, including from the command line. I followed the existing CONFIG_MODULE_SIG_FORCE and module.sig_enforce implementation. My intention is to make signature enforcement a build-time policy rather than depend on boot configuration. I fully agree with your point and that this patch alone does not protect against arbitrary command-line tampering. If required I can clarify the scope in a v2 ? > > > On Mon, 7 Sep 2026, Ayoub Zaki wrote: > >> Add DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE Kconfig option. When enabled, >> dm-verity always requires a valid root hash signature: require_signatures >> defaults to true and can no longer be cleared on the command line. When >> disabled, the existing require_signatures module parameter controls >> enforcement. >> >> Signed-off-by: Ayoub Zaki <ayoub.zaki@embetrix.com> >> --- >> Documentation/admin-guide/device-mapper/verity.rst | 5 +++++ >> drivers/md/Kconfig | 14 ++++++++++++++ >> drivers/md/dm-verity-verify-sig.c | 4 ++-- >> 3 files changed, 21 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst >> index eb9475d7e196..bb48c001aeac 100644 >> --- a/Documentation/admin-guide/device-mapper/verity.rst >> +++ b/Documentation/admin-guide/device-mapper/verity.rst >> @@ -163,6 +163,11 @@ root_hash_sig_key_desc <key_description> >> also gain new certificates at run time if they are signed by a certificate >> already in the secondary trusted keyring. >> >> + Whether a signature is required for every dm-verity device is controlled by >> + the dm_verity.require_signatures parameter which defaults to off. Setting >> + DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE makes it default to on in which case it >> + can no longer be turned off. >> + >> try_verify_in_tasklet >> If verity hashes are in cache and the IO size does not exceed the limit, >> verify data blocks in bottom half instead of workqueue. This option can >> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig >> index df27c7d066d2..59098d1f4534 100644 >> --- a/drivers/md/Kconfig >> +++ b/drivers/md/Kconfig >> @@ -610,6 +610,20 @@ config DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING >> >> If unsure, say N. >> >> +config DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE >> + bool "Require dm-verity root hash signature verification" >> + depends on DM_VERITY_VERIFY_ROOTHASH_SIG >> + help >> + Reject dm-verity devices that are created without a valid root hash >> + signature. Without this, whether a signature is required is decided >> + at boot time by the dm_verity.require_signatures parameter which >> + defaults to off. >> + >> + Enabling this makes that parameter default to on and it can then no >> + longer be turned off. >> + >> + If unsure, say N. >> + >> config DM_VERITY_FEC >> bool "Verity forward error correction support" >> depends on DM_VERITY >> diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c >> index b2b55c41e2cb..aadcf5e4a47c 100644 >> --- a/drivers/md/dm-verity-verify-sig.c >> +++ b/drivers/md/dm-verity-verify-sig.c >> @@ -21,8 +21,8 @@ static bool dm_verity_keyring_unsealed __ro_after_init; >> module_param_named(keyring_unsealed, dm_verity_keyring_unsealed, bool, 0444); >> MODULE_PARM_DESC(keyring_unsealed, "Leave the dm-verity keyring unsealed"); >> >> -static bool require_signatures; >> -module_param(require_signatures, bool, 0444); >> +static bool require_signatures = IS_ENABLED(CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE); >> +module_param(require_signatures, bool_enable_only, 0444); >> MODULE_PARM_DESC(require_signatures, >> "Verify the roothash of dm-verity hash tree"); >> >> >> base-commit: df2908090cda368b01ff43709f51890076c56157 >> -- >> 2.43.0 >> > Mit freundlichen Grüßen / Kind regards -- Ayoub Zaki Embedded Systems Consultant Vaihinger Straße 2/1 D-71634 Ludwigsburg Email : ayoub.zaki@embetrix.com Homepage : https://embetrix.com
On Mon, 21 Sep 2026, Ayoub Zaki wrote: > Hi, > > > On 9/21/26 11:46, Mikulas Patocka wrote: > > Hi > > > > The argument can be turned off even with your patch - by specifying > > dm_verity.require_signatures=0 on the kernel command line (read-only > > module parameters can be modified on the command line during boot). > > > > I'd like to know what kind of security problem does this patch try to > > solve. If the attacker can tamper with the kernel command line, he can > > already gain root (i.e. by using init=/bin/bash). > > > > Mikulas > > Thanks for reviewing. > I should have highlighted the change to bool_enable_only: with > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE=y it rejects attempts to clear > require_signatures, including from the command line. > I followed the existing CONFIG_MODULE_SIG_FORCE and module.sig_enforce > implementation. > My intention is to make signature enforcement a build-time policy rather than > depend on boot configuration. OK. I accepted the patch. It will be in 7.4. Mikulas > I fully agree with your point and that this patch alone does not protect > against arbitrary command-line tampering. > > If required I can clarify the scope in a v2 ?
© 2016 - 2026 Red Hat, Inc.