From: Mimi Zohar <zohar@linux.ibm.com>
To: "Guozihua (Scott)" <guozihua@huawei.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 19:17:37 -0400 [thread overview]
Message-ID: <97198ee38422fbb1891981ac5c41263d5b03b321.camel@linux.ibm.com> (raw)
In-Reply-To: <e2c5711c-6549-e81f-42a7-eec176b39d63@huawei.com>
On Fri, 2023-08-18 at 09:25 +0800, Guozihua (Scott) wrote:
> On 2023/8/17 22:19, Mimi Zohar wrote:
> > On Thu, 2023-08-17 at 14:13 +0800, GUO Zihua wrote:
[...]
> > 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!
Another proposal included all of the enabled TPM bank digests.
> 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.
True SHA1 is being phased out due to hash collisions. Verifying the
template data hash against the template data isn't necessary for the
attestation server to verify a TPM quote against any of the enabled TPM
banks. The attestation server walks the measurement list calculating
the bank specific template data hash. Breaking existing applications
is unreasonable.
> >
> > 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-dbata 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?
Defining additional pseudo filesystems would allow both the old and new
measurement list formats to be enabled at the same time.
--
thanks,
Mimi
next prev parent reply other threads:[~2023-08-18 23:18 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)
2023-08-18 23:17 ` Mimi Zohar [this message]
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=97198ee38422fbb1891981ac5c41263d5b03b321.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=corbet@lwn.net \
--cc=guozihua@huawei.com \
--cc=linux-integrity@vger.kernel.org \
/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