All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Ard Biesheuvel <ardb@kernel.org>
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:51:42 +0200	[thread overview]
Message-ID: <9ebd9e60-12dd-a6df-923c-dc9c6dbd709b@redhat.com> (raw)
In-Reply-To: <CAMj1kXFs6Z8VwqRMHf_OOZct4xNnNqiVOGBO0TtLfirg7WX8Eg@mail.gmail.com>

On 5/14/20 3:04 PM, Ard Biesheuvel wrote:
> On Thu, 14 May 2020 at 14:56, Javier Martinez Canillas

[snip]

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

Agreed.

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

That's what is not clear to me. For example, if a firmware follows the
spec what happens during EBS() when a TPM2 only supports the SHA-1 format?

Does the firmware always log events during EBS() even when it won't provide
a Final Events Table? If so, are the SHA-1 logs always incomplete?

What I wonder is if the firmware bug error should always be printed if the
crypto agile log format isn't used or only if isn't used and the firmware
provides a Final Events Table, which is a behavior that's out of the spec.

> 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");

Maybe mentioning that the missing logs are for events that happen during EBS()?

>                 goto out;
> +       }
> 
>         final_tbl = memremap(efi.tpm_final_log,
>                              sizeof(*final_tbl) + efi_tpm_final_log_size,
> 

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


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

Thread overview: 23+ 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
2020-05-14 13:51               ` Javier Martinez Canillas [this message]
2020-05-14 18:06                 ` Matthew Garrett
2020-05-15 15:55         ` Loïc Yhuel
2020-05-22 18:30 ` [tip: efi/urgent] " tip-bot2 for 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=9ebd9e60-12dd-a6df-923c-dc9c6dbd709b@redhat.com \
    --to=javierm@redhat.com \
    --cc=ardb@kernel.org \
    --cc=jarkko.sakkinen@linux.intel.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 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.