tpmdd-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Thiebaud Weksteen <tweek@google.com>
Cc: linux-efi@vger.kernel.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	linux-kernel@vger.kernel.org, Matthew Garrett <mjg59@google.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	tpmdd-devel@lists.sourceforge.net,
	jarkko.sakkinen@linux.intel.com, Peter Jones <pjones@redhat.com>
Subject: Re: [tpmdd-devel] [PATCH v2 2/3] efi: call get_event_log before ExitBootServices
Date: Mon, 18 Sep 2017 14:49:00 +0200	[thread overview]
Message-ID: <e29971dc-c266-95a6-86fa-0459490ef754@redhat.com> (raw)
In-Reply-To: <CA+zpnLfewoD7H1hZzCnVKi09a6+DvfGY8ZhFTYuKKFTBgSgoOA@mail.gmail.com>

On 09/18/2017 02:11 PM, Thiebaud Weksteen wrote:
> On Thu, Sep 14, 2017 at 12:24 PM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> On 09/11/2017 12:00 PM, Thiebaud Weksteen via tpmdd-devel wrote:

[snip]

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

I see, missed that. Thanks a lot for the explanation.

>>> + */
>>> +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.
>

Right. I wasn't sure if you wanted to distinguish between the two cases, but that
is simpler indeed.

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

  reply	other threads:[~2017-09-18 12:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11 10:00 [PATCH v2 0/3] Call GetEventLog before ExitBootServices Thiebaud Weksteen
2017-09-11 10:00 ` [PATCH v2 1/3] tpm: move tpm_eventlog.h outside of drivers folder Thiebaud Weksteen
2017-09-11 10:00 ` [PATCH v2 2/3] efi: call get_event_log before ExitBootServices Thiebaud Weksteen
     [not found]   ` <20170911100022.7251-3-tweek-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-09-13 14:49     ` kbuild test robot
     [not found]       ` <201709132252.uZyTCtDz%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-09-13 16:28         ` Thiebaud Weksteen via tpmdd-devel
2017-09-14 10:24     ` [tpmdd-devel] " Javier Martinez Canillas
     [not found]       ` <1f25ebdc-ab90-517f-b580-991a7cb5e25a-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-09-18 12:11         ` Thiebaud Weksteen
2017-09-18 12:49           ` Javier Martinez Canillas [this message]
2017-09-14 18:43     ` Jarkko Sakkinen
     [not found]       ` <20170914184126.eevnstwq3i6fiq4j-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-09-14 18:48         ` Matthew Garrett
2017-09-14 19:02           ` Jarkko Sakkinen
     [not found]             ` <20170914190247.rrbdzdexjjywxipf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-09-15  4:06               ` Jarkko Sakkinen
2017-09-18 12:28               ` Thiebaud Weksteen
     [not found]                 ` <CA+zpnLfs=DhW6kgbLV63_XzmKS7VnGGE0ecbFBZ0bu4wx3Jf+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-09-18 17:56                   ` Jarkko Sakkinen
2017-09-11 10:00 ` [PATCH v2 3/3] tpm: parse TPM event logs based on EFI table Thiebaud Weksteen
     [not found]   ` <20170911100022.7251-4-tweek-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-09-11 16:47     ` Jason Gunthorpe
2017-09-12  8:48       ` Thiebaud Weksteen
     [not found]         ` <20170912084851.z3ednbeojawnyxk2-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-09-18 12:38           ` Thiebaud Weksteen
2017-09-18 16:28             ` Jason Gunthorpe
2017-09-13 16:27     ` kbuild test robot
     [not found]       ` <201709140034.ESdZA8H8%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-09-13 16:43         ` Thiebaud Weksteen
2017-09-14 18:47   ` Jarkko Sakkinen
     [not found]     ` <20170914184732.uiypaz4yft777oc7-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-09-18 12:33       ` Thiebaud Weksteen
     [not found] ` <20170911100022.7251-1-tweek-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-09-13 18:59   ` [PATCH v2 0/3] Call GetEventLog before ExitBootServices Jarkko Sakkinen
2017-11-03 15:27   ` Jarkko Sakkinen
2017-09-14 10:21 ` [tpmdd-devel] " Javier Martinez Canillas

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=e29971dc-c266-95a6-86fa-0459490ef754@redhat.com \
    --to=javierm@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mjg59@google.com \
    --cc=pjones@redhat.com \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=tweek@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).