On 6/1/20 8:49 PM, Andy Lutomirski wrote: > > >> On Jun 1, 2020, at 5:14 PM, Daniel P. Smith <dpsm...@apertussolutions.com> >> wrote: >> >> On 6/1/20 3:39 PM, Andy Lutomirski wrote: >>>>> . >> >> In other words, the log for the relaunch to attest what is currently >> running is really no less useful than using the first launch log to >> attest to the what was running in the first launch. >> > > Maybe it would help if you give some examples of what’s actually in this log > and why anyone, Linux or otherwise, cares for any purpose other than > debugging. We’re talking about a log written by something like GRUB, right? > If so, I’m imagining things like: > > GRUB: loading such-and-such module > GRUB: loading the other module > GRUB: loading Linux at /boot/vmlinuz-whatever > GRUB: about to do the DRTM launch. Bye-bye. > > This is surely useful for debugging. But, if I understand your security > model correctly, it’s untrustworthy in the sense that this all comes from > before the DRTM launch and it could have been tampered with by SMM code or > even just a malicious USB stick. Or even a malicious compromised kernel on > the same machine. So you could hash this log into a PCR, but I don’t see what > you’ve accomplished by doing so. > > Or have I misunderstood what this log is? Perhaps you’re talking about > something else entirely. >
Oh I see! Yes we are discussing two different logs and yes there are two "logs" in play here. The start of this thread by Lukasz was on the TPM Event log. This is the log that is a record of TPM events for the DRTM chain, you can see the equivalent for SRTM with `cat /sys/kernel/security/tpm0/ascii_bios_measurements`(provided you system configuration is set up for SRTM). The second log, which for lack of a better name is the "debug log", is what you are referring to and is in another proposal that just recently came out, "[BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot"[1]. You are correct, the "debug log" is just filled with messages from components during the DRTM launch chain. While relaunch is being kept in mind as we work through getting first launch complete, not all aspects have been considered. What happens to the debug log on relaunch has no security relevance, as you called out earlier, and at this point I would say is an exercise for those integrating relaunch when it becomes available. I would expect them to treat it no different than the kmesg and syslog buffers on kexec/reboot, some may opt to kept a historical record and others will just let it disappear into the ether. Apologies that we got disconnected, I hope we are in sync now. [1] https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00223.html _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
