public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Nicolai Stange <nstange@suse.de>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: 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 00/13] ima: get rid of hard dependency on SHA-1
Date: Tue, 25 Mar 2025 21:58:47 -0400	[thread overview]
Message-ID: <fa71ecce9f7a92099b335a9495e83da43123e489.camel@linux.ibm.com> (raw)
In-Reply-To: <20250323140911.226137-1-nstange@suse.de>

On Sun, 2025-03-23 at 15:08 +0100, Nicolai Stange wrote:
> Hi,
> 
> this is v2 of the RFC series to disentangle IMA from its current
> dependency on a working SHA-1 implementation.
> 
> For reference, v1 can be found at [1].
> 
> Several options for when and how to invalidate unsupported TPM PCR banks
> by extending them with a unique constant had been discussed at the v1:
> a.) every single time a new entry gets added to the measurement list
> b.) or only once.
> 
> b.) is appealing, because it enables recognizing unsupported banks right
> away from their value, but comes at a significant additional complexity.
> Fortunately, it turned out that it's possible to develop b.) incrementally
> on top of a.), so this series can get truncated
> - after [5/13] ("ima: select CRYPTO_SHA256 from Kconfig") to get a.),
> - or after [9/13] ("ima: invalidate unsupported PCR banks only once")
>   to get a partial b.), invalidating unsupported banks only once for
>   each kernel booted, but redoing it for each kernel in a kexec chain,
> - or not at all to get the full b.), i.e. to skip reinvalidations even
>   from later kernels in the kexec chain if possible.
> 
> I would personally go for the full set, because it also enables some
> perhaps helpful diagnostics for the kernel log, but OTOH I'm clearly
> biased now because I've implemented everthing. So it's your judgement
> call now on how to proceed. Either way, I would send the next iteration in
> non-RFC mode with the full CC set. If you opted for a.) only, it would be
> a.) only, i.e. [1-5/13]. If you decided for b.), it might make sense to
> send in two batches to facilitate review: [1-9/13] first and the rest
> somewhen later.

Agreed.  Reviewing 1-9/13 is plenty.

To summarize/re-iterate:

- Don't rely on the "ima_hash" algorithm being the same for the kexec'ed kernel.
Create an "extra" bank for sha256, if the TPM is not configured for it.  We'll
be guaranteed at least one complete measurement list.

- Testing without SHA1 is difficult.  Maybe "select CRYPTO_SHA1" could be made
dependent on TPM 1.2 being enabled.

- From a testing perspective, it might be simpler to define a new Kconfig, but
I'm not sure it is really needed.  If SHA1 is configured as builtin, then
continue extending the unsupported TPM banks with SHA1.  Only if SHA1 isn't
configured, extend a single invalidate record (0xFE) per unsupported TPM bank.

- Should multiple PCRs be invalidated if the TPM bank hash algorithm was not
configured as builtin?  Or just invalidate the CONFIG_IMA_MEASURE_PCR_IDX?

- The number of unsupported TPM banks doesn't change until the next kexec.  No
need to keep re-calculating the number of TPM banks to extend.

Mimi

> 
> FWIW, I did some testing now, on the full series in a VM with a swtpm
> attached to it:
> - both with and without CONFIG_TCG_TPM2_HMAC (for [10/13] ("tpm:
>   authenticate tpm2_pcr_read()" coverage) and
> - with a focus on verifying everything related to the new invalidation
>   logic is working as intended.
> 
> Thanks a lot!
> 
> Nicolai
> 
> 
> 
> Changes to v1:
> - [v1 1/7] ("ima: don't expose runtime_measurements for unsupported
>   hashes"): no change.
> - [v1 2/7] ("ima: always create runtime_measurements sysfs file for
>   ima_hash"): no change.
> - [v1 3/7] ("ima: move INVALID_PCR() to ima.h"): moved to [v2 6/13],
>   otherwise no change.
> - [v1 4/7] ("ima: track the set of PCRs ever extended"):
>   moved to [v2 8/13], drop code restoring ima_extended_pcrs_mask at kexec,
>   update it from ima_pcr_extend() only if the tpm_pcr_extend() was
>   successful.
> - [v1 5/7] ("tpm: enable bank selection for PCR extend"): moved to
>   [v2 7/13], fix a bug by actually passing the skip mask from
>   tpm_pcr_extend() to tpm2_pcr_extend().
> - [v1 6/7] ("ima: invalidate unsupported PCR banks once at first use"):
>   gone, superseded by the new
>     [v2 3/13]  ("invalidate unsupported PCR banks")
>     [v2 9/13]  ("ima: invalidate unsupported PCR banks only once")
>     [v2 13/13] ("ima: don't re-invalidate unsupported PCR banks after
>               kexec")
> - [v1 7/7] ("ima: make SHA1 non-mandatory"): moved to [v2 4/13],
>   diff context updates due to ima_unsupported_tpm_banks_mask not
>   existing yet at this point in the series.
> 
> - [v2 5/13] ("ima: select CRYPTO_SHA256 from Kconfig"): new to
>   (hopefully) address feedback at [2].
> - [v2 10/13] ("tpm: authenticate tpm2_pcr_read()"): new, prerequisite
>   for the next in a sense.
> - [v2 11/13] ("ima: introduce ima_pcr_invalidated_banks() helper"): new,
>   prerequisite for [13/13].
> - [v2 12/13] ("ma: make ima_free_tfm()'s linkage extern"): new,
>   likewise a prerequisite for [13/13].
> 
> 
> [1] https://lore.kernel.org/r/20250313173339.3815589-1-nstange@suse.de
> [2] https://lore.kernel.org/r/4e760360258bda56fbcb8f67e865a7a4574c305a.camel@linux.ibm.com
> 
> 
> Nicolai Stange (13):
>   ima: don't expose runtime_measurements for unsupported hashes
>   ima: always create runtime_measurements sysfs file for ima_hash
>   ima: invalidate unsupported PCR banks
>   ima: make SHA1 non-mandatory
>   ima: select CRYPTO_SHA256 from Kconfig
>   ima: move INVALID_PCR() to ima.h
>   tpm: enable bank selection for PCR extend
>   ima: track the set of PCRs ever extended
>   ima: invalidate unsupported PCR banks only once
>   tpm: authenticate tpm2_pcr_read()
>   ima: introduce ima_pcr_invalidated_banks() helper
>   ima: make ima_free_tfm()'s linkage extern
>   ima: don't re-invalidate unsupported PCR banks after kexec
> 
>  drivers/char/tpm/tpm-interface.c      |  29 +++-
>  drivers/char/tpm/tpm.h                |   3 +-
>  drivers/char/tpm/tpm2-cmd.c           |  75 ++++++++-
>  include/linux/tpm.h                   |   3 +
>  security/integrity/ima/Kconfig        |  15 ++
>  security/integrity/ima/ima.h          |  12 ++
>  security/integrity/ima/ima_crypto.c   | 216 ++++++++++++++++++++++----
>  security/integrity/ima/ima_fs.c       |  41 +++--
>  security/integrity/ima/ima_policy.c   |   5 +-
>  security/integrity/ima/ima_queue.c    |  54 ++++++-
>  security/integrity/ima/ima_template.c |  84 +++++++++-
>  11 files changed, 471 insertions(+), 66 deletions(-)
> 


      parent reply	other threads:[~2025-03-26  2:04 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
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 ` Mimi Zohar [this message]

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=fa71ecce9f7a92099b335a9495e83da43123e489.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --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=nstange@suse.de \
    --cc=roberto.sassu@huawei.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