public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: edk2-devel@lists.01.org, "Jiewen Yao" <jiewen.yao@intel.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Stefan Berger" <stefanb@linux.vnet.ibm.com>
Subject: Re: Obtaining TCG final events on systems without TCG2 log support
Date: Thu, 13 Dec 2018 13:36:09 +0100	[thread overview]
Message-ID: <abc33bd2-c603-ed8d-ea4d-75c81138272f@redhat.com> (raw)
In-Reply-To: <20181213011750.bfzfyhrr4ufsiu6j@srcf.ucam.org>

+ Jiewen, Marc-André, Stefan

On 12/13/18 02:17, Matthew Garrett wrote:
> SetupEventLog() in Tcg2Dxe.c only installs the final event log 
> configuration table if SupportedEventLogs includes the TCG2 log format. 
> If the platform only supports the TCG1.2 log format then the final 
> events table isn't installed. However, ExitBootServices() should 
> generate an event even on systems that don't support the TCG2 log 
> format. How is an OS supposed to obtain the log of the 
> ExitBootServices() events in that case?
> 

I don't think it can.

You probably refer to the code below the comment "No need to handle
EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2", in SetupEventLog(). This code dates
back to commit fd46e831bc33 ("SecurityPkg: Update final event log
calculation.", 2016-01-18). And the commit message says, "... there is
no need to record TCG12 format log to final event log area ...".

Hence, the code is intentional. I even think the code is valid
(according to the spec [*]); I just think the commit message should have
said, "there is no *way* to record TCG12 format log to final event log
area". Because, IMO, the bug is in the spec.

[*] TCG EFI Protocol Specification
    Family “2.0”
    Level 00 Revision 00.13
    March 30, 2016

Here's why I think it's a spec bug:


(1) If EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 is *clear* in SupportedEventLogs,
then the platform advertizes GetEventLog() as unable to produce the
crypto agile log format.

In other words, the platform is unable to produce a log which consists
of TCG_PCR_EVENT2 entries, beyond the sole TCG_PCR_EVENT ("SHA1 format")
header entry.

Accordingly, GetEventLog() will fail with EFI_INVALID_PARAMETER, when
called with EventLogFormat=EFI_TCG2_EVENT_LOG_FORMAT_TCG_2. (BTW, I
think EFI_UNSUPPORTED would have been better for this, but I digress.)

(2) EFI_TCG2_FINAL_EVENTS_TABLE is defined with TCG_PCR_EVENT2 entries
*only*. TCG_PCR_EVENT is not accommodated.


That's the contradiction. If a platform is unable to produce
TCG_PCR_EVENT2 entries in GetEventLog(), it is fairly certainly also
unable to produce them in the final events table.

And, while the first *instance* of the limitation is conformant, via
SupportedEventLogs, the second instance of the same limitation isn't.

Thanks,
Laszlo


  reply	other threads:[~2018-12-13 12:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13  1:17 Obtaining TCG final events on systems without TCG2 log support Matthew Garrett
2018-12-13 12:36 ` Laszlo Ersek [this message]
2018-12-13 13:23   ` Yao, Jiewen
2018-12-13 18:51     ` Matthew Garrett
2018-12-13 18:55   ` Matthew Garrett
2018-12-14  9:32     ` Laszlo Ersek
2018-12-14 10:09       ` Yao, Jiewen
2018-12-14 10:22       ` Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abc33bd2-c603-ed8d-ea4d-75c81138272f@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox