Received-SPF: pass (google.com: domain of linux-kernel+bounces-157995-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 24 Apr 2024 21:36:26 -0700
From: Eric Biggers <ebiggers@kernel.org>
To: Fan Wu <wufan@linux.microsoft.com>
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 <deven.desai@linux.microsoft.com>
Subject: Re: [PATCH v17 20/21] Documentation: add ipe documentation
Message-ID: <20240425043626.GF1401@sol.localdomain>
References: <1712969764-31039-1-git-send-email-wufan@linux.microsoft.com>
 <1712969764-31039-21-git-send-email-wufan@linux.microsoft.com>
 <20240425041351.GD1401@sol.localdomain>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240425041351.GD1401@sol.localdomain>

On Wed, Apr 24, 2024 at 09:13:51PM -0700, Eric Biggers wrote:
> > +.. [#dmveritydigests] These hash algorithms are based on values accepted by dm-verity,
> > +                      specifically ``crypto_alloc_ahash`` in ``verity_ctr``; ``veritysetup``
> > +                      does support more algorithms than the list above. IPE does not impose
> > +                      any restrictions on the digest algorithm itself; thus, this list
> > +                      may be out of date.
> 
> References to specific functions and locations in the code tend to get out of
> date.  I think you mean something like: any hash algorithm that's supported by
> the Linux crypto API is supported.
> 

Also, this scheme looks buggy because it's directly reusing the crypto API's
algorithm name string as the digest name.  The crypto API lets you specify the
name of an algorithm, like "sha256", but it also lets you specify the name of a
particular *implementation* of an algorithm, like "sha256-ni" for the SHA-NI
accelerated implementation of sha256.  It looks like dm-verity just passes
through the name directly to the crypto API, and as a result it accepts names
like sha256-ni.  Since you're directly passing the same name into the
security_bdev_setintegrity() LSM hook, that would result in IPE being told that
the hash is "sha256-ni".  That doesn't make sense.  I think you want to be
passing in crypto_ahash_alg_name(v->tfm), not v->alg_name.

- Eric