From: Mike Snitzer <snitzer@redhat.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Deven Bowers" <deven.desai@linux.microsoft.com>,
linux-kernel@vger.kernel.org,
"Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com>,
"Mickaël Salaün" <mic@linux.microsoft.com>,
dm-devel@redhat.com, linux-integrity@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Milan Broz" <gmazyland@gmail.com>,
"Alasdair Kergon" <agk@redhat.com>,
"Jaskaran Khurana" <jaskarankhurana@linux.microsoft.com>
Subject: Re: [dm-devel] [PATCH v2] dm verity: Add support for signature verification with 2nd keyring
Date: Thu, 15 Oct 2020 12:52:29 -0400 [thread overview]
Message-ID: <20201015165229.GA5513@redhat.com> (raw)
In-Reply-To: <20201015150504.1319098-1-mic@digikod.net>
On Thu, Oct 15 2020 at 11:05am -0400,
Mickaël Salaün <mic@digikod.net> wrote:
> From: Mickaël Salaün <mic@linux.microsoft.com>
>
> Add a new configuration DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
> to enable dm-verity signatures to be verified against the secondary
> trusted keyring. Instead of relying on the builtin trusted keyring
> (with hard-coded certificates), the second trusted keyring can include
> certificate authorities from the builtin trusted keyring and child
> certificates loaded at run time. Using the secondary trusted keyring
> enables to use dm-verity disks (e.g. loop devices) signed by keys which
> did not exist at kernel build time, leveraging the certificate chain of
> trust model. In practice, this makes it possible to update certificates
> without kernel update and reboot, aligning with module and kernel
> (kexec) signature verification which already use the secondary trusted
> keyring.
>
> Cc: Alasdair Kergon <agk@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: Jaskaran Khurana <jaskarankhurana@linux.microsoft.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Cc: Milan Broz <gmazyland@gmail.com>
> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
> ---
>
> Previous version:
> https://lore.kernel.org/lkml/20201002071802.535023-1-mic@digikod.net/
>
> Changes since v1:
> * Extend the commit message (asked by Jarkko Sakkinen).
> * Rename the Kconfig "help" keyword according to commit 84af7a6194e4
> ("checkpatch: kconfig: prefer 'help' over '---help---'").
Can you please explain why you've decided to make this a Kconfig CONFIG
knob? Why not either add: a dm-verity table argument? A dm-verity
kernel module parameter? or both (to allow a particular default but then
per-device override)?
Otherwise, _all_ DM verity devices will be configured to use secondary
keyring fallback. Is that really desirable?
Regardless, I really don't see why a Kconfig knob is appropriate.
Mike
> ---
> drivers/md/Kconfig | 13 ++++++++++++-
> drivers/md/dm-verity-verify-sig.c | 9 +++++++--
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 30ba3573626c..1d68935e45ef 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -530,11 +530,22 @@ config DM_VERITY_VERIFY_ROOTHASH_SIG
> bool "Verity data device root hash signature verification support"
> depends on DM_VERITY
> select SYSTEM_DATA_VERIFICATION
> - help
> + help
> Add ability for dm-verity device to be validated if the
> pre-generated tree of cryptographic checksums passed has a pkcs#7
> signature file that can validate the roothash of the tree.
>
> + By default, rely on the builtin trusted keyring.
> +
> + If unsure, say N.
> +
> +config DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
> + bool "Verity data device root hash signature verification with secondary keyring"
> + depends on DM_VERITY_VERIFY_ROOTHASH_SIG
> + depends on SECONDARY_TRUSTED_KEYRING
> + help
> + Rely on the secondary trusted keyring to verify dm-verity signatures.
> +
> If unsure, say N.
>
> config DM_VERITY_FEC
> diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c
> index 614e43db93aa..29385dc470d5 100644
> --- a/drivers/md/dm-verity-verify-sig.c
> +++ b/drivers/md/dm-verity-verify-sig.c
> @@ -119,8 +119,13 @@ int verity_verify_root_hash(const void *root_hash, size_t root_hash_len,
> }
>
> ret = verify_pkcs7_signature(root_hash, root_hash_len, sig_data,
> - sig_len, NULL, VERIFYING_UNSPECIFIED_SIGNATURE,
> - NULL, NULL);
> + sig_len,
> +#ifdef CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
> + VERIFY_USE_SECONDARY_KEYRING,
> +#else
> + NULL,
> +#endif
> + VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
>
> return ret;
> }
>
> base-commit: bbf5c979011a099af5dc76498918ed7df445635b
> --
> 2.28.0
>
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Alasdair Kergon" <agk@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Deven Bowers" <deven.desai@linux.microsoft.com>,
"Jaskaran Khurana" <jaskarankhurana@linux.microsoft.com>,
"Milan Broz" <gmazyland@gmail.com>,
dm-devel@redhat.com, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com>,
"Mickaël Salaün" <mic@linux.microsoft.com>
Subject: Re: [PATCH v2] dm verity: Add support for signature verification with 2nd keyring
Date: Thu, 15 Oct 2020 12:52:29 -0400 [thread overview]
Message-ID: <20201015165229.GA5513@redhat.com> (raw)
In-Reply-To: <20201015150504.1319098-1-mic@digikod.net>
On Thu, Oct 15 2020 at 11:05am -0400,
Mickaël Salaün <mic@digikod.net> wrote:
> From: Mickaël Salaün <mic@linux.microsoft.com>
>
> Add a new configuration DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
> to enable dm-verity signatures to be verified against the secondary
> trusted keyring. Instead of relying on the builtin trusted keyring
> (with hard-coded certificates), the second trusted keyring can include
> certificate authorities from the builtin trusted keyring and child
> certificates loaded at run time. Using the secondary trusted keyring
> enables to use dm-verity disks (e.g. loop devices) signed by keys which
> did not exist at kernel build time, leveraging the certificate chain of
> trust model. In practice, this makes it possible to update certificates
> without kernel update and reboot, aligning with module and kernel
> (kexec) signature verification which already use the secondary trusted
> keyring.
>
> Cc: Alasdair Kergon <agk@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: Jaskaran Khurana <jaskarankhurana@linux.microsoft.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Cc: Milan Broz <gmazyland@gmail.com>
> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
> ---
>
> Previous version:
> https://lore.kernel.org/lkml/20201002071802.535023-1-mic@digikod.net/
>
> Changes since v1:
> * Extend the commit message (asked by Jarkko Sakkinen).
> * Rename the Kconfig "help" keyword according to commit 84af7a6194e4
> ("checkpatch: kconfig: prefer 'help' over '---help---'").
Can you please explain why you've decided to make this a Kconfig CONFIG
knob? Why not either add: a dm-verity table argument? A dm-verity
kernel module parameter? or both (to allow a particular default but then
per-device override)?
Otherwise, _all_ DM verity devices will be configured to use secondary
keyring fallback. Is that really desirable?
Regardless, I really don't see why a Kconfig knob is appropriate.
Mike
> ---
> drivers/md/Kconfig | 13 ++++++++++++-
> drivers/md/dm-verity-verify-sig.c | 9 +++++++--
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 30ba3573626c..1d68935e45ef 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -530,11 +530,22 @@ config DM_VERITY_VERIFY_ROOTHASH_SIG
> bool "Verity data device root hash signature verification support"
> depends on DM_VERITY
> select SYSTEM_DATA_VERIFICATION
> - help
> + help
> Add ability for dm-verity device to be validated if the
> pre-generated tree of cryptographic checksums passed has a pkcs#7
> signature file that can validate the roothash of the tree.
>
> + By default, rely on the builtin trusted keyring.
> +
> + If unsure, say N.
> +
> +config DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
> + bool "Verity data device root hash signature verification with secondary keyring"
> + depends on DM_VERITY_VERIFY_ROOTHASH_SIG
> + depends on SECONDARY_TRUSTED_KEYRING
> + help
> + Rely on the secondary trusted keyring to verify dm-verity signatures.
> +
> If unsure, say N.
>
> config DM_VERITY_FEC
> diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c
> index 614e43db93aa..29385dc470d5 100644
> --- a/drivers/md/dm-verity-verify-sig.c
> +++ b/drivers/md/dm-verity-verify-sig.c
> @@ -119,8 +119,13 @@ int verity_verify_root_hash(const void *root_hash, size_t root_hash_len,
> }
>
> ret = verify_pkcs7_signature(root_hash, root_hash_len, sig_data,
> - sig_len, NULL, VERIFYING_UNSPECIFIED_SIGNATURE,
> - NULL, NULL);
> + sig_len,
> +#ifdef CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
> + VERIFY_USE_SECONDARY_KEYRING,
> +#else
> + NULL,
> +#endif
> + VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
>
> return ret;
> }
>
> base-commit: bbf5c979011a099af5dc76498918ed7df445635b
> --
> 2.28.0
>
next prev parent reply other threads:[~2020-10-15 16:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 15:05 [dm-devel] [PATCH v2] dm verity: Add support for signature verification with 2nd keyring Mickaël Salaün
2020-10-15 15:05 ` Mickaël Salaün
2020-10-15 16:52 ` Mike Snitzer [this message]
2020-10-15 16:52 ` Mike Snitzer
2020-10-16 8:29 ` [dm-devel] " Mickaël Salaün
2020-10-16 8:29 ` Mickaël Salaün
2020-10-16 8:49 ` [dm-devel] " Mickaël Salaün
2020-10-16 8:49 ` Mickaël Salaün
2020-10-16 11:08 ` [dm-devel] " Milan Broz
2020-10-16 11:08 ` Milan Broz
2020-10-16 12:19 ` [dm-devel] " Mickaël Salaün
2020-10-16 12:19 ` Mickaël Salaün
2020-10-23 10:20 ` [dm-devel] " Mickaël Salaün
2020-10-23 10:20 ` Mickaël Salaün
2020-10-23 15:11 ` [dm-devel] " Mike Snitzer
2020-10-23 15:11 ` Mike Snitzer
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=20201015165229.GA5513@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=deven.desai@linux.microsoft.com \
--cc=dm-devel@redhat.com \
--cc=gmazyland@gmail.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jaskarankhurana@linux.microsoft.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mic@digikod.net \
--cc=mic@linux.microsoft.com \
/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.