public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Laszlo Ersek <lersek@redhat.com>, Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"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:23:35 +0000	[thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F452EC4@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <abc33bd2-c603-ed8d-ea4d-75c81138272f@redhat.com>

Right.
I think we are trying to deprecate the old SHA1 support, because SHA1 is considered as unsecure algorithm.
We are moving to crypto agile. As such, we do not see the need to support old style event log.

Thank you
Yao Jiewen


> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, December 13, 2018 8:36 PM
> To: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: edk2-devel@lists.01.org; Yao, Jiewen <jiewen.yao@intel.com>;
> Marc-André Lureau <marcandre.lureau@redhat.com>; Stefan Berger
> <stefanb@linux.vnet.ibm.com>
> Subject: Re: [edk2] Obtaining TCG final events on systems without TCG2 log
> support
> 
> + 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 13:23 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
2018-12-13 13:23   ` Yao, Jiewen [this message]
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=74D8A39837DF1E4DA445A8C0B3885C503F452EC4@shsmsx102.ccr.corp.intel.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