On Tue, 2023-12-26 at 10:36 -0500, Ken Goldman wrote: > > On 12/25/2023 8:00 AM, Guozihua (Scott) wrote: > >> 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? > > > > From a security and verification viewpoint, I think you are correct. > The template hash is redundant, and can always be calculated from the > template data. In that sense, the template hash can be removed. > > On the other hand there is one benefit to the template hash. If there is > a bug in the software that creates the event log or the software that > consumes the event log, the template hash may help to determine which > event has a bug. > > If the new event log has a template hash, I do believe that it also > needs a hash algorithm. Scott are you asking, since the template data hash is redudant, why bother changing the measurement list format to support other digest algorithms? After removing the SHA1 digest, perhaps SHA1 would not need to be configured in the kernel. -- thanks, Mimi
