Re: [RFC][PATCH] ima: add crypto agility support for template-hash algorithm

Guozihua (Scott)
2023-12-25T13:00:19Z

On 2023/12/22 6:05, Mimi Zohar wrote:
> 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 and Enrico,

As we are extending all supported algorithms of a PCR bank, does
algorithm of template-hash still matters?

--
Best
GUO Zihua