linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: "Loïc Yhuel" <loic.yhuel@gmail.com>,
	"Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com>,
	"Matthew Garrett" <mjg59@google.com>,
	linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: [PATCH] tpm: check event log version before reading final events
Date: Thu, 14 May 2020 15:04:25 +0200	[thread overview]
Message-ID: <CAMj1kXFs6Z8VwqRMHf_OOZct4xNnNqiVOGBO0TtLfirg7WX8Eg@mail.gmail.com> (raw)
In-Reply-To: <789b40ad-3017-b2cc-df15-d2739787d05e@redhat.com>

On Thu, 14 May 2020 at 14:56, Javier Martinez Canillas
<javierm@redhat.com> wrote:
>
> Hello Ard,
>
> On 5/14/20 2:28 PM, Ard Biesheuvel wrote:
> > On Thu, 14 May 2020 at 13:33, Javier Martinez Canillas
>
> [snip]
>
> >>
> >> The Final Events Table contains the logs for any events that are triggered
> >> by ExitBootServices().
> >
> > This is inaccurate afaik. The final events table contains all events
> > that were logged since the first call to Tcg2::GetEventLog()
> >
>
> Yes, you are correct. After the first call to GetEventLog(), all events
> are logged in both the event log and the Final Events Table IIUC.
>
> But what I tried to say is that only the Final Events Table can be used to
> obtain the logs for the events triggered by ExitBootServices(). I'll try
> to make it more clear if I post this as a proper patch.
>
> I still don't know if something like that would be acceptable or if we
> should just consider a bug if a firmware doesn't conform with the spec.
>

I'd like Matt's and Jarkko's take on this - for me, considering it a
bug is just fine. I just want to understand what exactly to warn
about, since we currently silently ignore the lack of a final events
table, while it apparently defeats the purpose of having a log in the
first.

So given that the ordinary event log will contain everything *except*
the events that were logged during EBS(), I agree that the log may
still be useful if those final events only affected PCRs that you
don't care about.

Something like the below perhaps? Should we suppress the warning for
tables of size 0x0?

diff --git a/drivers/char/tpm/eventlog/efi.c b/drivers/char/tpm/eventlog/efi.c
index 6bb023de17f1..65bfee8e636d 100644
--- a/drivers/char/tpm/eventlog/efi.c
+++ b/drivers/char/tpm/eventlog/efi.c
@@ -62,8 +62,10 @@ int tpm_read_log_efi(struct tpm_chip *chip)

        if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR ||
            efi_tpm_final_log_size == 0 ||
-           tpm_log_version != EFI_TCG2_EVENT_LOG_FORMAT_TCG_2)
+           tpm_log_version != EFI_TCG2_EVENT_LOG_FORMAT_TCG_2) {
+               pr_warn(FW_BUG "TPM Final Event table not found - some
events may be missing\n");
                goto out;
+       }

        final_tbl = memremap(efi.tpm_final_log,
                             sizeof(*final_tbl) + efi_tpm_final_log_size,

  reply	other threads:[~2020-05-14 13:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12  4:01 [PATCH] tpm: check event log version before reading final events Loïc Yhuel
2020-05-12  6:44 ` Ard Biesheuvel
2020-05-12 11:40   ` Loïc Yhuel
2020-05-12 12:30     ` Ard Biesheuvel
2020-05-14 10:51       ` Jarkko Sakkinen
2020-05-14  1:09   ` Jarkko Sakkinen
2020-05-14  8:10     ` Ard Biesheuvel
2020-05-14 23:44       ` Jarkko Sakkinen
2020-05-12 17:45 ` Javier Martinez Canillas
2020-05-12 18:45 ` Jerry Snitselaar
2020-05-12 20:08 ` Matthew Garrett
2020-05-14 10:53   ` Jarkko Sakkinen
2020-05-14 11:28     ` Loïc Yhuel
2020-05-14 11:31       ` Ard Biesheuvel
2020-05-15  0:03         ` Jarkko Sakkinen
2020-05-14 11:33       ` Javier Martinez Canillas
2020-05-14 12:28         ` Ard Biesheuvel
2020-05-14 12:56           ` Javier Martinez Canillas
2020-05-14 13:04             ` Ard Biesheuvel [this message]
2020-05-14 13:51               ` Javier Martinez Canillas
2020-05-14 18:06                 ` Matthew Garrett
2020-05-15 15:55         ` Loïc Yhuel

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=CAMj1kXFs6Z8VwqRMHf_OOZct4xNnNqiVOGBO0TtLfirg7WX8Eg@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=javierm@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=loic.yhuel@gmail.com \
    --cc=mjg59@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).