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
