Hi Jaskaran,

On Thu, Jun 27, 2019 at 06:49:58PM -0700, Jaskaran Singh Khurana wrote:

On Thu, 27 Jun 2019, Eric Biggers wrote:

quoted

Hi Jaskaran, one comment (I haven't reviewed this in detail):

On Wed, Jun 19, 2019 at 12:10:48PM -0700, Jaskaran Khurana wrote:

quoted

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index db269a348b20..2d658a3512cb 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig

@@ -475,6 +475,7 @@ config DM_VERITY
 	select CRYPTO
 	select CRYPTO_HASH
 	select DM_BUFIO
+	select SYSTEM_DATA_VERIFICATION
 	---help---
 	  This device-mapper target creates a read-only device that
 	  transparently validates the data on one underlying device against

diff --git a/drivers/md/Makefile b/drivers/md/Makefile
index be7a6eb92abc..3b47b256b15e 100644
--- a/drivers/md/Makefile
+++ b/drivers/md/Makefile

@@ -18,7 +18,7 @@ dm-cache-y	+= dm-cache-target.o dm-cache-metadata.o dm-cache-policy.o \
 		    dm-cache-background-tracker.o
 dm-cache-smq-y   += dm-cache-policy-smq.o
 dm-era-y	+= dm-era-target.o
-dm-verity-y	+= dm-verity-target.o
+dm-verity-y	+= dm-verity-target.o dm-verity-verify-sig.o
 md-mod-y	+= md.o md-bitmap.o
 raid456-y	+= raid5.o raid5-cache.o raid5-ppl.o
 dm-zoned-y	+= dm-zoned-target.o dm-zoned-metadata.o dm-zoned-reclaim.o

Perhaps this should be made optional and controlled by a kconfig option
CONFIG_DM_VERITY_SIGNATURE_VERIFICATION, similar to CONFIG_DM_VERITY_FEC?

CONFIG_SYSTEM_DATA_VERIFICATION brings in a lot of stuff, which might be
unnecessary for some dm-verity users.  Also, you've already separated most of
the code out into a separate .c file anyway.

- Eric

Hello Eric,

This started with a config (see V4). We didnot want scripts that pass this
parameter to suddenly stop working if for some reason the verification is
turned off so the optional parameter was just parsed and no validation
happened if the CONFIG was turned off. This was changed to a commandline
parameter after feedback from the community, so I would prefer to keep it
*now* as commandline parameter. Let me know if you are OK with this.

Regards,
JK

Sorry, I haven't been following the whole discussion.  (BTW, you sent out
multiple versions both called "v4", and using a cover letter for a single patch
makes it unnecessarily difficult to review.)  However, it appears Milan were
complaining about the DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE option which set the
policy for signature verification, *not* the DM_VERITY_VERIFY_ROOTHASH_SIG
option which enabled support for signature verification.  Am I missing
something?  You can have a module parameter which controls the "signatures
required" setting, while also allowing people to compile out kernel support for
the signature verification feature.

Sure, it means that the signature verification support won't be guaranteed to be
present when dm-verity is.  But the same is true of the hash algorithm (e.g.
sha512), and of the forward error correction feature.  Since the signature
verification is nontrivial and pulls in a lot of other kernel code which might
not be otherwise needed (via SYSTEM_DATA_VERIFICATION), it seems a natural
candidate for putting the support behind a Kconfig option.

BTW, I'm doing something similar for fs-verity; see
https://patchwork.kernel.org/patch/11008077/.  The signature verification
support is behind CONFIG_FS_VERITY_BUILTIN_SIGNATURES, but the policy of
requiring signatures is a sysctl fs.verity.require_signatures.

- Eric