linux-kernel - Re: [GRUB PATCH RFC 00/18] i386: Intel TXT secure launcher

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <01cc067e-f2f2-d4da-6944-2724dbc7b61e@apertussolutions.com>
Date:   Mon, 1 Jun 2020 21:29:05 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Lukasz Hawrylko <lukasz.hawrylko@...ux.intel.com>,
        grub-devel@....org, LKML <linux-kernel@...r.kernel.org>,
        trenchboot-devel@...glegroups.com, X86 ML <x86@...nel.org>,
        alexander.burmashev@...cle.com,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        eric.snowberg@...cle.com, javierm@...hat.com,
        kanth.ghatraju@...cle.com,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        krystian.hebel@...eb.com, michal.zygowski@...eb.com,
        Matthew Garrett <mjg59@...gle.com>, phcoder@...il.com,
        piotr.krol@...eb.com, Peter Jones <pjones@...hat.com>,
        Ross Philipson <ross.philipson@...cle.com>
Subject: Re: [GRUB PATCH RFC 00/18] i386: Intel TXT secure launcher

On 6/1/20 8:49 PM, Andy Lutomirski wrote:
> 
> 
>> On Jun 1, 2020, at 5:14 PM, Daniel P. Smith <dpsmith@...rtussolutions.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