All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolai Stange <nstange@suse.de>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Nicolai Stange <nstange@suse.de>,
	 Roberto Sassu <roberto.sassu@huawei.com>,
	 Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Eric Snowberg <eric.snowberg@oracle.com>,
	 Jarkko Sakkinen <jarkko@kernel.org>,
	 James Bottomley <James.Bottomley@HansenPartnership.com>,
	 linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 02/13] ima: always create runtime_measurements sysfs file for ima_hash
Date: Wed, 26 Mar 2025 14:46:03 +0100	[thread overview]
Message-ID: <87wmcboqg4.fsf@> (raw)
In-Reply-To: <fbd87f01b5463e399900df8dcb094a9039bd589f.camel@linux.ibm.com> (Mimi Zohar's message of "Wed, 26 Mar 2025 09:17:05 -0400")

Mimi Zohar <zohar@linux.ibm.com> writes:

> On Wed, 2025-03-26 at 09:21 +0100, Nicolai Stange wrote:
>> Mimi Zohar <zohar@linux.ibm.com> writes:
>> 
>> > On Sun, 2025-03-23 at 15:09 +0100, Nicolai Stange wrote:

>> > "ima_hash" is the default file hash algorithm.  Re-using it as the default
>> > complete measurement list assumes that the subsequent kexec'ed kernels configure
>> > and define it as the default file hash algorithm as well, which might not be the
>> > case.
>> 
>> I don't really see why the ima_hashes would have to match between kexecs
>> for this to work -- all events' template hashes are getting recreated
>> from scratch anyway after kexec (ima_restore_measurement_list() ->
>> ima_calc_field_array_hash()).
>> 
>> That is, if ima_hash=sha256 first, and ima_hash=sha384 after kexec, one
>> would have *runtime_measurements_sha256 first and
>> *runtime_measurements_sha384 after kexec. And both had exclusively
>> template hashes of their respective algo in them each.
>> 
>> What am I missing?
>
> Your solution would work nicely, if the "ima_hash" algorithm could be guaranteed
> to be built into the kernel.  It's highly unlikely someone would choose a hash
> algorithm not built into kernel, but it is possible.  hash_setup() only verifies
> that the hash algorithm is a valid name.

But ima_init_ima_crypto(), hence the whole IMA __init, would fail if
ima_hash was unavailable at __init time?

Thanks,

Nicolai

> Either fix hash_setup() to guarantee that the chosen hash algorithm is built
> into the kernel or use the CONFIG_IMA_DEFAULT_HASH and add a Kconfig to select
> the hash algorithm.  This would be in lieu of v2 05/13.
>
>> > Drop this patch.
>> 
>> Fine by me, but just to confirm, in case there's no TPM attached and
>> SHA1 was disabled, there would be no /sys/*/*runtime_measurement* at all
>> then. Is that Ok?
>
> Of course not.  :)
>
>> ima_hash was chosen here only, because after this series, it will be the
>> only single algorithm guaranteed to be available.
>
> With the proposed changes to "[RFC PATCH v2 05/13] ima: select CRYPTO_SHA256
> from Kconfig', SHA256 would be added to the "extra" measurements if the TPM
> SHA256 bank is disabled.


-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

  reply	other threads:[~2025-03-26 13:46 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-23 14:08 [RFC PATCH v2 00/13] ima: get rid of hard dependency on SHA-1 Nicolai Stange
2025-03-23 14:08 ` [RFC PATCH v2 01/13] ima: don't expose runtime_measurements for unsupported hashes Nicolai Stange
2025-03-25 14:26   ` Mimi Zohar
2025-03-26  7:44     ` Nicolai Stange
2025-03-26 13:28       ` Mimi Zohar
2025-03-23 14:09 ` [RFC PATCH v2 02/13] ima: always create runtime_measurements sysfs file for ima_hash Nicolai Stange
2025-03-24 14:31   ` Mimi Zohar
2025-03-26  8:21     ` Nicolai Stange
2025-03-26 13:17       ` Mimi Zohar
2025-03-26 13:46         ` Nicolai Stange [this message]
2025-03-26 14:48           ` Mimi Zohar
2025-03-23 14:09 ` [RFC PATCH v2 03/13] ima: invalidate unsupported PCR banks Nicolai Stange
2025-03-23 21:18   ` James Bottomley
2025-03-25  1:03     ` Mimi Zohar
2025-03-25 15:44       ` James Bottomley
2025-03-26  8:45         ` Nicolai Stange
2025-03-24 15:05   ` Mimi Zohar
2025-03-26  9:01     ` Nicolai Stange
2025-03-26 14:18       ` Mimi Zohar
2025-03-26 14:31         ` Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 04/13] ima: make SHA1 non-mandatory Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 05/13] ima: select CRYPTO_SHA256 from Kconfig Nicolai Stange
2025-03-25 15:17   ` Mimi Zohar
2025-03-23 14:09 ` [RFC PATCH v2 06/13] ima: move INVALID_PCR() to ima.h Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 07/13] tpm: enable bank selection for PCR extend Nicolai Stange
2025-03-23 20:41   ` Jarkko Sakkinen
2025-03-26  9:45     ` Nicolai Stange
2025-03-26  1:18   ` Mimi Zohar
2025-03-26  9:41     ` Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 08/13] ima: track the set of PCRs ever extended Nicolai Stange
2025-03-25 17:09   ` Mimi Zohar
2025-03-26  9:56     ` Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 09/13] ima: invalidate unsupported PCR banks only once Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 10/13] tpm: authenticate tpm2_pcr_read() Nicolai Stange
2025-03-23 17:25   ` James Bottomley
2025-03-26  6:34     ` Nicolai Stange
2025-03-23 20:35   ` Jarkko Sakkinen
2025-03-23 14:09 ` [RFC PATCH v2 11/13] ima: introduce ima_pcr_invalidated_banks() helper Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 12/13] ima: make ima_free_tfm()'s linkage extern Nicolai Stange
2025-03-23 14:09 ` [RFC PATCH v2 13/13] ima: don't re-invalidate unsupported PCR banks after kexec Nicolai Stange
2025-03-26  1:58 ` [RFC PATCH v2 00/13] ima: get rid of hard dependency on SHA-1 Mimi Zohar

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=87wmcboqg4.fsf@ \
    --to=nstange@suse.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eric.snowberg@oracle.com \
    --cc=jarkko@kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.