Date:   Mon, 18 Sep 2017 14:11:23 +0200
From:   Thiebaud Weksteen <tweek@...gle.com>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     linux-efi@...r.kernel.org,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        linux-kernel@...r.kernel.org, Matthew Garrett <mjg59@...gle.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        tpmdd-devel@...ts.sourceforge.net, jarkko.sakkinen@...ux.intel.com,
        Peter Jones <pjones@...hat.com>
Subject: Re: [tpmdd-devel] [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 12:24 PM, Javier Martinez Canillas
<javierm@...hat.com> wrote:
> On 09/11/2017 12:00 PM, Thiebaud Weksteen via tpmdd-devel wrote:
>> With TPM 2.0 specification, the event logs may only be accessible by
>> calling an EFI Boot Service. Modify the EFI stub to copy the log area to
>> a new Linux-specific EFI configuration table so it remains accessible
>> once booted.
>>
>> When calling this service, it is possible to specify the expected format
>> of the logs: TPM 1.2 (SHA1) or TPM 2.0 ("Crypto Agile"). For now, only the
>> first format is retrieved.
>>
>> Signed-off-by: Thiebaud Weksteen <tweek@...gle.com>
>> ---
>
> [snip]
>
>> +void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
>> +{
>
> [snip]
>
>> +
>> +     /* Allocate space for the logs and copy them. */
>> +     status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
>> +                             sizeof(*log_tbl) + log_size,
>> +                             (void **) &log_tbl);
>> +
>> +     if (status != EFI_SUCCESS) {
>> +             efi_printk(sys_table_arg,
>> +                        "Unable to allocate memory for event log\n");
>> +             return;
>> +     }
>
> If this fails or any previous error that will prevent the event log table + logs
> to be allocated, shouldn't tpm_read_log_efi() be notified somehow? Since AFAICT
> it will still try to access them even if the EFI allocate_pool did not succeed.
>

The implicit part that covers this case is in
drivers/firmware/efi/efi.c. The match_config_table function will go
through all the installed configuration tables and only fill up the
associated member of the efi structure if it exists. In this case,
.tpm_log will remains at EFI_INVALID_TABLE_ADDR unless
efi_call_early(install_configuration_table, ...) is called. So no
further processing is to be expected should the allocation failed.

>> + */
>> +int __init efi_tpm_eventlog_init(void)
>> +{
>> +     struct linux_efi_tpm_eventlog *tbl;
>> +     unsigned int tbl_size;
>> +
>
> The functions efi_retrieve_tpm2_eventlog_1_2() and tpm_read_log_efi() are using
> log_tbl as variable name, so I would use it here too for consistency.
>

Done.

>> +     if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
>> +             return 0;
>> +
>> +     tbl = early_memremap(efi.tpm_log, sizeof(*tbl));
>> +     if (!tbl) {
>> +             pr_err("Failed to map TPM Event Log table @ 0x%lx\n",
>> +                     efi.tpm_log);
>> +             return -ENOMEM;
>> +     }
>> +
>
> Same question than before, if this fails then the table + logs memory won't be
> reserved but tpm_read_log_efi() will still try to access it. I'm not sure what
> is the correct way to notify though, maybe setting efi.tpm_log to 0 and then in
> tpm_read_log_efi() check efi.tpm_log for 0 or EFI_INVALID_TABLE_ADDR instead?
>

That's right. To keep it simple, it might be easier to just set
tpm_log to EFI_INVALID_TABLE_ADDR if that happens. Added in the next
version of the patch set.

>> +     tbl_size = sizeof(*tbl) + tbl->size;
>> +     memblock_reserve(efi.tpm_log, tbl_size);
>> +     early_memunmap(tbl, sizeof(*tbl));
>> +     return 0;
>
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement
> Red Hat

Powered by blists - more mailing lists