All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Laszlo Ersek <lersek@redhat.com>, Peter Jones <pjones@redhat.com>
Cc: "Amarnath Valluri" <amarnath.valluri@intel.com>,
	"qemu devel list" <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [Qemu-devel] TPM status
Date: Thu, 29 Jun 2017 16:07:07 +0200	[thread overview]
Message-ID: <a19eaa37-7bcd-be8b-8afb-092ef55b261f@redhat.com> (raw)
In-Reply-To: <f1e02018-7920-7c17-d5c9-91271d6f093c@linux.vnet.ibm.com>

Hello Stefan,

On 06/28/2017 10:57 PM, Stefan Berger wrote:
> On 06/28/2017 12:44 PM, Laszlo Ersek wrote:
>> On 06/28/17 17:22, Peter Jones wrote:
>>> On Tue, Jun 27, 2017 at 12:12:50PM -0400, Stefan Berger wrote:

[snip]

>>>>
>>>> To support measurements logs to be written by the firmware, e.g.
>>>> SeaBIOS, a TCPA table is implemented. This table provides a 64kb
>>>> buffer where the firmware can write its log into.
>>> How does this work if we boot with edk2?
>> My expectation is that it doesn't work at all, without doing some OVMF
>> platform enablement first. (See
>> <https://bugzilla.tianocore.org/show_bug.cgi?id=594>.) My plan is to use
>> Stefan's document as a starting point for the edk2 / OVMF investigation
>> -- one known and one unknown are better than two unknowns (to me).
>>> Do we get what's described in
>>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
>>> instead of this interface?  As well as it?  It'd be good to have some
>>> text about this here.
>> I don't think that Stefan has spent any time on EFI enablement, so this
>> part of the document will have to be written later, once there is any
>> EFI-related functionality we can document. (I expect.)
> 
> Right, I did not spend any time on EFI. I suppose the ACPI tables going to a BIOS are also useful for EFI.
> 
> For BIOS there is unfortunately only a spec for TPM 1.2, none anymore for
> TPM2, at least back then when I last looked for it. So I ended up passing
> that TCPA table that has the pointer for the logging area also in case of
> a TPM 2. So SeaBIOS writes its log to it in both cases, following the TPM 2

But this isn't correct from a TPM2 pov, right? Because the TPM2 spec says
that the ACPI table that contains the TPM2.0 event logs is the TPM2 table.

So instead the LASA field in the passed TPM2 ACPI table should point to the
allocated buffer used by the firmware to store the event logs.

> format form the EFI specs for the entries. The Linux driver in the meantime
> has modified the code so  that it doesn't show the log anymore in case of
> TPM 2 :-( . I think the above referenced specs would explain how the logging

Do you mean that in the past Linux exposed the securityfs files with the event
logs for TPM2 chips as well? My understanding is that Linux does the correct
thing now, since as mentioned the TCPA table should only be used for TPM1.2.

There are patches posted to add Linux support to read the event logs for TPM2
chips but from the TPM2 ACPI table. I see that hose haven't landed yet though:

https://patchwork.kernel.org/project/tpmdd-devel/list/?submitter=7143

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

  parent reply	other threads:[~2017-06-29 14:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-14 13:51 [Qemu-devel] TPM status Laszlo Ersek
2017-06-14 15:00 ` Stefan Berger
2017-06-27 16:12 ` Stefan Berger
2017-06-27 16:32   ` Laszlo Ersek
2017-06-29 19:31     ` Stefan Berger
2017-07-01 20:45       ` Laszlo Ersek
2017-06-28 15:22   ` Peter Jones
2017-06-28 16:44     ` Laszlo Ersek
2017-06-28 20:57       ` Stefan Berger
2017-06-28 21:26         ` Laszlo Ersek
2017-06-29 14:07         ` Javier Martinez Canillas [this message]
2017-06-29 16:59           ` Stefan Berger
2017-06-29 12:39   ` Javier Martinez Canillas
2017-06-29 16:09     ` Stefan Berger
2017-06-29 23:12       ` Javier Martinez Canillas
2017-06-30  0:55         ` Stefan Berger

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-all 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=a19eaa37-7bcd-be8b-8afb-092ef55b261f@redhat.com \
    --to=javierm@redhat.com \
    --cc=amarnath.valluri@intel.com \
    --cc=dgilbert@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pjones@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanb@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.