From: Silvia Sisinni <silvia.sisinni@polito.it>
To: Mimi Zohar <zohar@linux.ibm.com>,
Enrico Bravi <enrico.bravi@polito.it>,
linux-integrity@vger.kernel.org, roberto.sassu@huawei.com
Subject: Re: [RFC][PATCH] ima: add crypto agility support for template-hash algorithm
Date: Tue, 9 Jan 2024 18:05:30 +0100 [thread overview]
Message-ID: <7ffd4706-5629-4309-8dd0-790fdc05c7c1@polito.it> (raw)
In-Reply-To: <89cea05a61ac4616774446683bf612165ba2f43c.camel@linux.ibm.com>
Il 12/21/2023 11:05 PM, Mimi Zohar ha scritto:
> On Thu, 2023-12-21 at 15:38 +0100, Enrico Bravi wrote:
>> Hi Mimi,
>>
>> thank you for your feedback.
>>
>> On 19/12/23 21:54, Mimi Zohar wrote:
>>> Hi Enrico,
>>>
>>> On Thu, 2023-12-14 at 15:51 +0100, Enrico Bravi wrote:
>>>> The purpose of this patch is to add the possibility to configure the hash
>>>> algorithm to use when calculating the template-hash.
>>>
>>> The patch description should be written in the imperative mood. For an
>>> explanation, please refer to "Describe your changes" in
>>> Documentation/process/submitting-patches.rst.>
>>> For example:
>>>
>>> The second field of the IMA measurement list, the template data hash,
>>> contains a fixed sized SHA1 digest. Add support to replace the SHA1
>>> digest with other hash algorithms. For backwards compatability, only
>>> the new larger digests will be prefixed with ...
>>>
>>>> The ima_template_hash command line parameter has been introduced to enable
>>>> this configuration.
>>>
>>> The term "ima_template_hash" could be misconstrued to refer to the hash
>>> algorithm used to calculate the file digest. To differentiate between
>>> the hash algorithm used to calculate the file digest, the term
>>> 'ima_template_data_hash' is longer, but I think clearer.
>>
>> Yes you're right, this name is ambiguous.
>>
>>>> The entry will contain the hash_algo_name before the actual template-hash,
>>>> separated by a colon (:).
>>>
>>> This chnage will break existing userspace applications, unless the SHA1
>>> digest isn't prefixed.
>>
>> Yes, in the current patch, this value is present even in the case of SHA1. We
>> can modifying the patch by omitting it in the case of SHA1; as an alternative,
>> the addition of the hash algorithm information can be made configurable in the
>> ima log to maintain backward compatibility with existing applications.
>
> After thinking about this some more, I realized that we didn't discuss
> carrying the measurement list across kexec. How will the kexec'ed
> kernel be able to differentiate between the original and new
> measurement list? Neither the Kconfig nor making SHA1 backwards
> compatible address this. How will attestation servers be able to
> differentiate between the two logs?
>
> Obviously the new measurement list with larger digests won't be
> backwards compatible. Can we support carrying the original measurement
> list across kexec to a new kernel?
>
> As long we're making changes to the IMA measurement list, we should
> mention that we could include multiple digests, but I don't think it is
> necessary.
>
>>>> An example of the resulting ima log is the following:
>>>>
>>>> 10 sha256:64326[...]25313 ima-ng sha1:5fc9b[...]974e6 boot_aggregate
>>>> 10 sha256:afd64[...]e3123 ima-ng sha1:5a493[...]f9566 /init
>>>> 10 sha256:99329[...]a6353 ima-ng sha1:8c87d[...]3d8c7 /usr/bin/sh
>>>> 10 sha256:a16ad[...]2ac0e ima-ng sha1:59d4b[...]330b0 /etc/ld.so.cache
>
> The template DATA_FMT_DIGEST_WITH_ALGO field is a composite field
> defined as <hash algo> + ':' + '\0' + digest. The above ascii display
> looks like the template composite field, but isn't. It is two separate
> fields. Perhaps it should look differently as well. Consider instead
> of a string use the hash_algo value (include/uapi/linux/hash_info.h).
>
> binary measurement log: <pcr> <hash_algo> <digest_len> <digest>
>
Hi Mimi,
sorry for the delay, thank you for your comments.
What you are highlighting about the difference with the
DATA_FMT_DIGEST_WITH_ALGO field is correct. To avoid this problem we
could add the normalization of the measurement list, dumping it with
SHA1 without prefix. This would resolve the problem because the
restoring of the measurement list implies the re-computing of all the
digests corresponding to all the hash algorithms configured for PCR
banks in the TPM. So, by adding this modification, kexec could execute
both a kernel compatible with this feature and a kernel that is not.
BR,
Silvia
prev parent reply other threads:[~2024-01-09 17:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 14:51 [RFC][PATCH] ima: add crypto agility support for template-hash algorithm Enrico Bravi
2023-12-19 20:54 ` Mimi Zohar
2023-12-21 14:38 ` Enrico Bravi
2023-12-21 22:05 ` Mimi Zohar
2023-12-25 13:00 ` Guozihua (Scott)
2023-12-26 15:36 ` Ken Goldman
2023-12-27 14:03 ` Mimi Zohar
2024-01-09 17:05 ` Silvia Sisinni [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=7ffd4706-5629-4309-8dd0-790fdc05c7c1@polito.it \
--to=silvia.sisinni@polito.it \
--cc=enrico.bravi@polito.it \
--cc=linux-integrity@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).