Obtaining TCG final events on systems without TCG2 log support

Obtaining TCG final events on systems without TCG2 log support

[Matthew Garrett]

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?
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Obtaining TCG final events on systems without TCG2 log support

[Laszlo Ersek]

+ 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

Re: Obtaining TCG final events on systems without TCG2 log support

[Yao, Jiewen]

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

Re: Obtaining TCG final events on systems without TCG2 log support

[Matthew Garrett]

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

Re: Obtaining TCG final events on systems without TCG2 log support

[Matthew Garrett]

On Thu, Dec 13, 2018 at 01:36:09PM +0100, Laszlo Ersek wrote:

> (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.

If a platform is unable to produce them in the final events table then 
it's violating the spec. If the platform only offers the 1.2 log format 
then it seems reasonable to expect that the events in the final events 
table would only contain a SHA1, but a TCG_PCR_EVENT2 structure that 
only contains SHA1s isn't significantly more complicated than an old 
style event.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Obtaining TCG final events on systems without TCG2 log support

[Laszlo Ersek]

On 12/13/18 19:55, Matthew Garrett wrote:
> On Thu, Dec 13, 2018 at 01:36:09PM +0100, Laszlo Ersek wrote:
> 
>> (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.
> 
> If a platform is unable to produce them in the final events table then 
> it's violating the spec.

The question is why it's made impossible to comply with the spec if the
platform only supports the 1.2 format.

> If the platform only offers the 1.2 log format 
> then it seems reasonable to expect that the events in the final events 
> table would only contain a SHA1, but a TCG_PCR_EVENT2 structure that 
> only contains SHA1s isn't significantly more complicated than an old 
> style event.
> 

OK... I guess that can be a valid interpretation. Would you please file
a TianoCore BZ ticket about it, as a feature request?

- URL: https://bugzilla.tianocore.org
- Product: Tianocore Feature Requests
- Component: Code
- Package: SecurityPkg

(I'm assuming this isn't a regression, i.e., it's not the case that the
feature used to work, but commit fd46e831bc33 regressed it.)

Thanks,
Laszlo

Re: Obtaining TCG final events on systems without TCG2 log support

[Yao, Jiewen]

thanks
i will raise the topic in next tcg pc client meeting.


thank you!
Yao, Jiewen


> 在 2018年12月14日，下午5:32，Laszlo Ersek <lersek@redhat.com> 写道：
> 
>> On 12/13/18 19:55, Matthew Garrett wrote:
>>> On Thu, Dec 13, 2018 at 01:36:09PM +0100, Laszlo Ersek wrote:
>>> 
>>> (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.
>> 
>> If a platform is unable to produce them in the final events table then 
>> it's violating the spec.
> 
> The question is why it's made impossible to comply with the spec if the
> platform only supports the 1.2 format.
> 
>> If the platform only offers the 1.2 log format 
>> then it seems reasonable to expect that the events in the final events 
>> table would only contain a SHA1, but a TCG_PCR_EVENT2 structure that 
>> only contains SHA1s isn't significantly more complicated than an old 
>> style event.
>> 
> 
> OK... I guess that can be a valid interpretation. Would you please file
> a TianoCore BZ ticket about it, as a feature request?
> 
> - URL: https://bugzilla.tianocore.org
> - Product: Tianocore Feature Requests
> - Component: Code
> - Package: SecurityPkg
> 
> (I'm assuming this isn't a regression, i.e., it's not the case that the
> feature used to work, but commit fd46e831bc33 regressed it.)
> 
> Thanks,
> Laszlo

Re: Obtaining TCG final events on systems without TCG2 log support

[Matthew Garrett]

On Fri, Dec 14, 2018 at 10:32:29AM +0100, Laszlo Ersek wrote:
> On 12/13/18 19:55, Matthew Garrett wrote:
> > If a platform is unable to produce them in the final events table then 
> > it's violating the spec.
> 
> The question is why it's made impossible to comply with the spec if the
> platform only supports the 1.2 format.

If a platform can't implement the spec then the platform violates the 
spec :)

> > If the platform only offers the 1.2 log format 
> > then it seems reasonable to expect that the events in the final events 
> > table would only contain a SHA1, but a TCG_PCR_EVENT2 structure that 
> > only contains SHA1s isn't significantly more complicated than an old 
> > style event.
> > 
> 
> OK... I guess that can be a valid interpretation. Would you please file
> a TianoCore BZ ticket about it, as a feature request?

Will do.

> (I'm assuming this isn't a regression, i.e., it's not the case that the
> feature used to work, but commit fd46e831bc33 regressed it.)

It looks like fd46e831bc33 didn't change anything significant here, so I 
don't think this is a regression.

-- 
Matthew Garrett | mjg59@srcf.ucam.org