Received: by 2002:a89:48b:0:b0:1f5:f2ab:c469 with SMTP id a11csp850983lqd; Wed, 24 Apr 2024 20:57:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVUxvZR7D9I3Az4m03La+woKBd89/pygZcrQ/EiYj371zCl0UkK7rUb8907zJBFXiwYkUkvYxpOKWbyl/ueZqGCdx54CZVPuCHizu8SHQ== X-Google-Smtp-Source: AGHT+IGmlmFEEld8z3n7JfL3jM0I+XNiRChVcSacz/KKtIAKWVCYO9fNvI0/3zhZuMiH5XFiMIgR X-Received: by 2002:a05:620a:e88:b0:78d:6b37:ee7a with SMTP id w8-20020a05620a0e8800b0078d6b37ee7amr4204101qkm.50.1714017423438; Wed, 24 Apr 2024 20:57:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714017423; cv=pass; d=google.com; s=arc-20160816; b=M99ZTAUKBZuG7+CkItFahMft7iZ8627+eMBtMEQSuV0t7ow43PvE6/RaZotadSVzd7 XJ2VJqaZILR6c27+6ElNEtDu7kmLezJ1dA/GHwWO8DzoZ5zH6qhUdzKos4+NIXtXQ9+O BSU9RpgwMA/o+0tWyzAioSuquVAd0lFngWwWuqodb0ciHqad3SgYsl+Cc7zUPWQSI3Y0 coQuMEPYaseU/ql9pDX7ss/RlLp5RDF0fmI4IUqx1cjrZMOuDCGsZAWie/1ABTi552r6 1XFS+pDQHIMy0QYcTAbFGRQ0tF/u7fTTVSbd1IbRITW9tbkzq/88Zb6KOp0rRtDfRAan CSxQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=pO6R8WHqWksWdBYlNm+cys9R3wN31DRTooOxxl+vr/4=; fh=tBL3q0tIRR0gzVsb9JkPDpuT1fOoR1ERDu7WXJYo2as=; b=RPfdWAcHu6OhoHVDt4G3a/2bYgaQ/6mZ90Ibt4NIwIs+25Q9FnTfdwRg3tFERu9Q6I eXh5GR974D80JjT40bym3H/uBI3rbBzoKTdKWXqxgNrmAGsWvjC5R0ZFqvYGkqpyrwIt FnKwLPSBjHIOaFkbccZhQKt+qxPDFI0bFH1b3deBIVcDiatS4KjxUYxsw0/rLib5X5Vi BUcfX8HmP86i3dWsBSKC5In3Mwgt8yHfHZfj+n8VVrL+cXJEOMxCpI/R+gHuCH7ma3cn j6w5EYynSDPBGibQeU3f4siqxUoJJ2+6QJIoCGbxatTKKAypgLCCXKllX3Zz56e9TnNo bn0g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TZra8rhA; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-157983-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-157983-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id f11-20020a05620a12eb00b0078eff6f05c8si16181626qkl.569.2024.04.24.20.57.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 20:57:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-157983-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TZra8rhA; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-157983-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-157983-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 2FF9B1C20A20 for ; Thu, 25 Apr 2024 03:57:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C4C41376E1; Thu, 25 Apr 2024 03:56:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TZra8rhA" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC7D01AACB; Thu, 25 Apr 2024 03:56:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714017410; cv=none; b=MlQwOIFGnaGbRUI8eaeVycDlM41X8HG2L+tSdK1S+I+YtcZ9JtTaj4ZrvkpFYtb0N1x7hhc8e5WCUUx+2m6/JI92ltJ6mjfqSUqI2+zI2+FBJXHDITHNZXH5Zchjr4DGkeXu/7J3Y8DUUn8P+3yUmhwiGOsiNJIL3Ogn4SMOKG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714017410; c=relaxed/simple; bh=xbvsl7p/tNI3FsAriBnf2RoEGr8k3R2uelHe67Dhz9o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ST/8KRxCEF0rYilvPXBHzOCS3yLE1/Xc0wAfjgk4ykieGW8cdwpL/lSVPEtFEA3O1WAweGI5Xh97RmG1K0xEravThpS98xW5aM6MAxF+uxcITnliHq7ZvMXQ14vPjy3Pa8bmuqEoHNl0gpOdCGUT8oYq1X/bZDlWG4XyZ7u6oNA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TZra8rhA; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE01AC113CC; Thu, 25 Apr 2024 03:56:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714017409; bh=xbvsl7p/tNI3FsAriBnf2RoEGr8k3R2uelHe67Dhz9o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TZra8rhAGO4C6E2iOW3rX/yd1YzAQbNgxnEMcEnXuyHAXwubnXPoZrPbUSD33Fu9J SxCM6i6yNtp0Gon16iAdINv7SG0lYFFTTwqw3OcfVSawRcWpbBIcnenmRTQdYMY2zN 3Vjp42P8iLlstsam2vyZCnqHhxfhrZxWKFNTc3vpcuGvd+RCxQYUh9ckvfJOuJaUY0 B5Dh12B+u/WvV4RA4obddHQ761gBea8YlSd95x/iENRuz26pdL+DALTCqc2EkE/6Zm KPD6Qe07CbTXQKGn+phST2tqBUgSWVTPjUSRotLn4LtgX65Q7AZ1h5c5X5Q879qrtY L0I9gmI/S5f6g== Date: Wed, 24 Apr 2024 20:56:47 -0700 From: Eric Biggers To: Fan Wu Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com, tytso@mit.edu, axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org, eparis@redhat.com, paul@paul-moore.com, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, fsverity@lists.linux.dev, linux-block@vger.kernel.org, dm-devel@lists.linux.dev, audit@vger.kernel.org, linux-kernel@vger.kernel.org, Deven Bowers Subject: Re: [PATCH v17 13/21] dm verity: consume root hash digest and expose signature data via LSM hook Message-ID: <20240425035647.GC1401@sol.localdomain> References: <1712969764-31039-1-git-send-email-wufan@linux.microsoft.com> <1712969764-31039-14-git-send-email-wufan@linux.microsoft.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1712969764-31039-14-git-send-email-wufan@linux.microsoft.com> On Fri, Apr 12, 2024 at 05:55:56PM -0700, Fan Wu wrote: > dm verity: consume root hash digest and expose signature data via LSM hook As in the fsverity patch, nothing is being "consumed" here. This patch adds a supplier, not a consumer. I think you mean something like: expose root digest and signature to LSMs. > diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c > index bb5da66da4c1..fbb83c6fd99c 100644 > --- a/drivers/md/dm-verity-target.c > +++ b/drivers/md/dm-verity-target.c > @@ -22,6 +22,8 @@ > #include > #include > #include > +#include > +#include > > #define DM_MSG_PREFIX "verity" > > @@ -1017,6 +1019,38 @@ static void verity_io_hints(struct dm_target *ti, struct queue_limits *limits) > blk_limits_io_min(limits, limits->logical_block_size); > } > > +#ifdef CONFIG_SECURITY > + > +static int verity_init_sig(struct dm_verity *v, const void *sig, > + size_t sig_size) > +{ > + v->sig_size = sig_size; > + v->root_digest_sig = kmemdup(sig, v->sig_size, GFP_KERNEL); > + if (!v->root_digest) > + return -ENOMEM; root_digest_sig, not root_digest > +#ifdef CONFIG_SECURITY > + > +static int verity_finalize(struct dm_target *ti) > +{ > + struct block_device *bdev; > + struct dm_verity_digest root_digest; > + struct dm_verity *v; > + int r; > + > + v = ti->private; > + bdev = dm_disk(dm_table_get_md(ti->table))->part0; > + root_digest.digest = v->root_digest; > + root_digest.digest_len = v->digest_size; > + root_digest.alg = v->alg_name; > + > + r = security_bdev_setintegrity(bdev, LSM_INT_DMVERITY_ROOTHASH, &root_digest, > + sizeof(root_digest)); > + if (r) > + return r; > + > + r = security_bdev_setintegrity(bdev, > + LSM_INT_DMVERITY_SIG_VALID, > + v->root_digest_sig, > + v->sig_size); The signature is only checked if CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y, whereas this code is built whenever CONFIG_SECURITY=y. So this seems like the same issue that has turned up elsewhere in the IPE patchset, where IPE is (apparently) happy with any signature, even one that hasn't been checked... > diff --git a/drivers/md/dm-verity.h b/drivers/md/dm-verity.h > index 20b1bcf03474..89e862f0cdf6 100644 > --- a/drivers/md/dm-verity.h > +++ b/drivers/md/dm-verity.h > @@ -43,6 +43,9 @@ struct dm_verity { > u8 *root_digest; /* digest of the root block */ > u8 *salt; /* salt: its size is salt_size */ > u8 *zero_digest; /* digest for a zero block */ > +#ifdef CONFIG_SECURITY > + u8 *root_digest_sig; /* digest signature of the root block */ > +#endif /* CONFIG_SECURITY */ No, it's not a signature of the root block, at least not directly. It's a signature of the root digest (the digest of the root block). > diff --git a/include/linux/dm-verity.h b/include/linux/dm-verity.h > new file mode 100644 > index 000000000000..a799a8043d85 > --- /dev/null > +++ b/include/linux/dm-verity.h > @@ -0,0 +1,12 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef _LINUX_DM_VERITY_H > +#define _LINUX_DM_VERITY_H > + > +struct dm_verity_digest { > + const char *alg; > + const u8 *digest; > + size_t digest_len; > +}; > + > +#endif /* _LINUX_DM_VERITY_H */ > diff --git a/include/linux/security.h b/include/linux/security.h > index ac0985641611..9e46b13a356c 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -84,7 +84,8 @@ enum lsm_event { > }; > > enum lsm_integrity_type { > - __LSM_INT_MAX > + LSM_INT_DMVERITY_SIG_VALID, > + LSM_INT_DMVERITY_ROOTHASH, > }; Shouldn't struct dm_verity_digest be defined next to LSM_INT_DMVERITY_ROOTHASH? It's the struct that's associated with it. It seems weird to create a brand new header that just contains this one LSM related definition, when there's already a header for the LSM definitions that even includes the related value LSM_INT_DMVERITY_ROOTHASH. - Eric