linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Wed, 24 Apr 2024 21:36:26 -0700	[thread overview]
Message-ID: <20240425043626.GF1401@sol.localdomain> (raw)
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

  reply	other threads:[~2024-04-25  4:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-13  0:55 [PATCH v17 00/21] Integrity Policy Enforcement LSM (IPE) Fan Wu
2024-04-13  0:55 ` [PATCH v17 01/21] security: add ipe lsm Fan Wu
2024-04-13  0:55 ` [PATCH v17 02/21] ipe: add policy parser Fan Wu
2024-04-13  0:55 ` [PATCH v17 03/21] ipe: add evaluation loop Fan Wu
2024-04-13  0:55 ` [PATCH v17 04/21] ipe: add LSM hooks on execution and kernel read Fan Wu
2024-04-13  0:55 ` [PATCH v17 05/21] initramfs|security: Add a security hook to do_populate_rootfs() Fan Wu
2024-04-13  0:55 ` [PATCH v17 06/21] ipe: introduce 'boot_verified' as a trust provider Fan Wu
2024-04-13  0:55 ` [PATCH v17 07/21] security: add new securityfs delete function Fan Wu
2024-04-13  0:55 ` [PATCH v17 08/21] ipe: add userspace interface Fan Wu
2024-04-13  0:55 ` [PATCH v17 09/21] uapi|audit|ipe: add ipe auditing support Fan Wu
2024-04-13  0:55 ` [PATCH v17 10/21] ipe: add permissive toggle Fan Wu
2024-04-13  0:55 ` [PATCH v17 11/21] block,lsm: add LSM blob and new LSM hooks for block device Fan Wu
2024-04-13  0:55 ` [PATCH v17 12/21] dm: add finalize hook to target_type Fan Wu
2024-04-13  0:55 ` [PATCH v17 13/21] dm verity: consume root hash digest and expose signature data via LSM hook Fan Wu
2024-04-25  3:56   ` Eric Biggers
2024-04-25 20:23     ` Fan Wu
2024-04-13  0:55 ` [PATCH v17 14/21] ipe: add support for dm-verity as a trust provider Fan Wu
2024-04-13  0:55 ` [PATCH v17 15/21] security: add security_inode_setintegrity() hook Fan Wu
2024-04-13  0:55 ` [PATCH v17 16/21] fsverity: expose verified fsverity built-in signatures to LSMs Fan Wu
2024-04-25  3:36   ` Eric Biggers
2024-04-13  0:56 ` [PATCH v17 17/21] ipe: enable support for fs-verity as a trust provider Fan Wu
2024-04-25  3:42   ` Eric Biggers
2024-04-25  4:20     ` Eric Biggers
2024-04-13  0:56 ` [PATCH v17 18/21] scripts: add boot policy generation program Fan Wu
2024-04-13  0:56 ` [PATCH v17 19/21] ipe: kunit test for parser Fan Wu
2024-04-13  0:56 ` [PATCH v17 20/21] Documentation: add ipe documentation Fan Wu
2024-04-15 12:11   ` Bagas Sanjaya
2024-04-15 14:56     ` Randy Dunlap
2024-04-17 10:05       ` Bagas Sanjaya
2024-04-25  4:13   ` Eric Biggers
2024-04-25  4:36     ` Eric Biggers [this message]
2024-04-13  0:56 ` [PATCH v17 21/21] MAINTAINERS: ipe: add ipe maintainer information Fan Wu

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=20240425043626.GF1401@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=agk@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=deven.desai@linux.microsoft.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=eparis@redhat.com \
    --cc=fsverity@lists.linux.dev \
    --cc=jmorris@namei.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=snitzer@kernel.org \
    --cc=tytso@mit.edu \
    --cc=wufan@linux.microsoft.com \
    --cc=zohar@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).