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

I don't see how that follows - regardless of whether or not we'd like to 
deprecate SHA1 support, people use it. There's little value in having an 
incomplete event log.

On Thu, Dec 13, 2018 at 01:23:35PM +0000, Yao, Jiewen wrote:
> 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
-- 
Matthew Garrett | mjg59@srcf.ucam.org


  reply	other threads:[~2018-12-13 18:51 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
2018-12-13 18:51     ` Matthew Garrett [this message]
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=20181213185136.u7kwuenifopvgorp@srcf.ucam.org \
    --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