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> -- thanks, Mimi
