public inbox for linux-integrity@vger.kernel.org
 help / color / mirror / Atom feed
From: "Guozihua (Scott)" <guozihua@huawei.com>
To: Mimi Zohar <zohar@linux.ibm.com>, Jonathan Corbet <corbet@lwn.net>
Cc: <linux-integrity@vger.kernel.org>
Subject: Re: [RFC PATCH -next] ima: Make tpm hash configurable
Date: Fri, 18 Aug 2023 09:25:59 +0800	[thread overview]
Message-ID: <e2c5711c-6549-e81f-42a7-eec176b39d63@huawei.com> (raw)
In-Reply-To: <90b4b5573182ec68b2da2f9ef2bc6567d724f8f1.camel@linux.ibm.com>

Hi Mimi,

On 2023/8/17 22:19, Mimi Zohar wrote:
> Hi Scott,
> 
> This patch changes the TPM PCR hash algorithm and value in the IMA
> measurement list.  The Subject line doesn't convey that.
> 
> On Thu, 2023-08-17 at 14:13 +0800, GUO Zihua wrote:
>> TPM2 chips supports algorithms other than SHA1. However, the original
>> IMA design hardcode template hash to be SHA1.
> 
> True, IMA initially calculated and extended a SHA1 hash into the TPM,
> but Roberto addressed that years ago.  Refer to commit  1ea973df6e21
> ("ima: Calculate and extend PCR with digests in ima_template_entry").
> 
> IMA now calculates and extends each of the enabled TPM banks with the
> appropriate hash value.  The PCR value in the IMA measurement list
> remains SHA1.  Attestation servers can first verify the SHA1 template
> hash as stored in the measurement list.  Then it can walk the IMA
> measurement list calculating the template data hash based on the per
> TPM bank algorithm to verify the TPM bank PCR value. 

Yeah I noticed that. However the fact that only SHA1 digest is included
in the measurement list means that the file-data hash and file hint is
effectively "protected" by just a SHA1 digest, and at the end of the day
for remote attestation only SHA1 digest is available.

> 
>>
>> This patch added CONFIG_IMA_TEMPLATE_HASH as well as ima_tpm_hash=
>> cmdline argument for configurating template hash. The usage is simuliar
>> to CONFIG_IMA_DEFAULT_HASH and ima_hash=. The configured hash is checked
>> against TPM and make sure that the hash algorithm is supported by
>> ima_tpm_chip.
>>
>> To accommodate the change, we must put a digest length into binary
>> measurement list items. The binary measurement list item format is
>> changed to this:
>> 	16bit-le=pcr#
>> 	16bit-le=template digest size
>> 	char[n]=template digest
>> 	32bit-le=template name size
>> 	char[n]=template name
>> 	[eventdata length]
>> 	eventdata[n]=template specific data
>> The first element is now a 16bit pcr number and a 16bit template digest
>> size, instead of the original 32bit pcr number.
>>
>> The format of ascii_measurement_list is also changed. For sha1 template
>> hash, the format is the same as before. For other hash algorithms, a
>> hash name is prepended as such:
>> "sha256:30ee3e25620478759600be00e06fda7b4fe23bbf575621d480400d536cf54f5b"
>> Signed-off-by: GUO Zihua <guozihua@huawei.com>
> 
> Other proposals have changed the hard coded hash algorithm and PCR
> value from SHA1 to SHA256.  Both that proposal and this will break
> existing userspace applications.

This is the part I would like to "RFC" on, and thanks for the comment!
In deed this change should break userspace as well as all the existing
remote attestation implementation. It should be better to have a brand
new file for this.
> 
> Before we can introduce this sort of change, we would need to introduce
> an IMA measurement list version.  Perhaps its time to define an IMA
> security critical-data record, which would include this and other
> information.  The measurement list itself would need to include a
> version number.
> 
I guess one of the easy way to do it is to make a
ascii_runtime_measurements_ng and binary_runtime_measurements_ng, which
contains a changed template supporting configurable template hash. What
do you think?

-- 
Best
GUO Zihua


  reply	other threads:[~2023-08-18  1:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17  6:13 [RFC PATCH -next] ima: Make tpm hash configurable GUO Zihua
2023-08-17 14:19 ` Mimi Zohar
2023-08-18  1:25   ` Guozihua (Scott) [this message]
2023-08-18 23:17     ` Mimi Zohar
2023-08-19  8:43       ` Guozihua (Scott)
2023-08-28 21:05       ` Ken Goldman
2023-08-30  9:32         ` Guozihua (Scott)
2023-08-30 19:26           ` Ken Goldman
2023-08-30  9:14       ` Guozihua (Scott)
2023-08-30 12:27         ` Mimi Zohar
2023-08-29 14:09   ` Ken Goldman
2023-08-28 20:35 ` Ken Goldman
2023-08-30  9:38   ` Guozihua (Scott)

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=e2c5711c-6549-e81f-42a7-eec176b39d63@huawei.com \
    --to=guozihua@huawei.com \
    --cc=corbet@lwn.net \
    --cc=linux-integrity@vger.kernel.org \
    --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