linux-kernel - Re: [PATCH v17 20/21] Documentation: add ipe documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 24 Apr 2024 21:36:26 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Fan Wu <wufan@...ux.microsoft.com>
Cc: corbet@....net, zohar@...ux.ibm.com, jmorris@...ei.org,
	serge@...lyn.com, tytso@....edu, axboe@...nel.dk, agk@...hat.com,
	snitzer@...nel.org, eparis@...hat.com, paul@...l-moore.com,
	linux-doc@...r.kernel.org, linux-integrity@...r.kernel.org,
	linux-security-module@...r.kernel.org, fsverity@...ts.linux.dev,
	linux-block@...r.kernel.org, dm-devel@...ts.linux.dev,
	audit@...r.kernel.org, linux-kernel@...r.kernel.org,
	Deven Bowers <deven.desai@...ux.microsoft.com>
Subject: Re: [PATCH v17 20/21] Documentation: add ipe documentation

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