linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: luca.boccassi@gmail.com
To: dm-devel@lists.linux.dev
Cc: snitzer@kernel.org, jmorris@namei.org, paul@paul-moore.com,
	James.Bottomley@hansenpartnership.com,
	linux-security-module@vger.kernel.org
Subject: [PATCH v2] dm verity: add support for signature verification with platform keyring
Date: Thu,  4 Jul 2024 16:48:49 +0100	[thread overview]
Message-ID: <20240704154849.3751846-1-luca.boccassi@gmail.com> (raw)
In-Reply-To: <20240617220037.594792-1-luca.boccassi@gmail.com>

From: Luca Boccassi <bluca@debian.org>

Add a new configuration CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING
that enables verifying dm-verity signatures using the platform keyring,
which is populated using the UEFI DB certificates.

This is useful for self-enrolled systems that do not use MOK, as the
secondary keyring which is already used for verification, if the
relevant kconfig is enabled, is linked to the machine keyring, which
gets its certificates loaded from MOK. On some datacenter/virtual/cloud
deployments that roll their own OS it can happen to deploy one's own
certificate chain directly in DB on first boot in unattended mode,
rather than relying on MOK, as the latter typically requires
interactive authentication to enroll. Another use case is for those who
self-enroll on their laptop/desktop, and do not use shim/mok at all.
This is quite common, for example it's the main way Arch users do
SecureBoot, and there's an entire ecosystem around this workflow, using
sbctl and friends. systemd-boot provides facilities to self-enroll on
first boot, for example. Another use case is in CIs, where we boot with
a locally built systemd-boot, self-enroll in EDK2, run some tests, and
then throw away the VM. This is the case in systemd's upstream CI that
uses mkosi, for example.

Default to the same value as DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
if not otherwise specified, as it is likely that if one wants to use
MOK certificates to verify dm-verity volumes, DB certificates are going
to be used too. Those who do not wish for the DB certificates to make
their way in the kernel keyrings can already set the MokIgnoreDB UEFI
variable, and importing will be skipped. This changes fully respects
that workflow, as it just uses the platform keyring if it is populated,
and changes nothing otherwise.

Signed-off-by: Luca Boccassi <bluca@debian.org>
---
v2: update commit message to better reflect the use case and the functionality,
    as per feedback from James

 drivers/md/Kconfig                | 10 ++++++++++
 drivers/md/dm-verity-verify-sig.c |  7 +++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 35b1080752cd..1e9db8e4acdf 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -540,6 +540,16 @@ config DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
 
 	  If unsure, say N.
 
+config DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING
+	bool "Verity data device root hash signature verification with platform keyring"
+	default DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
+	depends on DM_VERITY_VERIFY_ROOTHASH_SIG
+	depends on INTEGRITY_PLATFORM_KEYRING
+	help
+	  Rely also on the platform keyring to verify dm-verity signatures.
+
+	  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 4836508ea50c..d351d7d39c60 100644
--- a/drivers/md/dm-verity-verify-sig.c
+++ b/drivers/md/dm-verity-verify-sig.c
@@ -126,6 +126,13 @@ int verity_verify_root_hash(const void *root_hash, size_t root_hash_len,
 				NULL,
 #endif
 				VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
+#ifdef CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING
+	if (ret == -ENOKEY)
+		ret = verify_pkcs7_signature(root_hash, root_hash_len, sig_data,
+					sig_len,
+					VERIFY_USE_PLATFORM_KEYRING,
+					VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
+#endif
 
 	return ret;
 }
-- 
2.39.2


      parent reply	other threads:[~2024-07-04 15:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240617220037.594792-1-luca.boccassi@gmail.com>
2024-07-04  9:12 ` [PATCH] dm verity: add support for signature verification with platform keyring Luca Boccassi
2024-07-04 15:48 ` luca.boccassi [this message]

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=20240704154849.3751846-1-luca.boccassi@gmail.com \
    --to=luca.boccassi@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=snitzer@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).