tpmdd-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Nayna <nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Petr Vandrovec <petr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table
Date: Tue, 4 Apr 2017 00:01:25 +0530	[thread overview]
Message-ID: <58E294FD.10504@linux.vnet.ibm.com> (raw)
In-Reply-To: <58DCBE41.3060507-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>



On 03/30/2017 01:43 PM, Petr Vandrovec wrote:
> Nayna wrote:
>>
>>
>> On 03/29/2017 01:13 PM, Petr Vandrovec wrote:
>>> Hi Peter,
>>>
>>> This series of 4 patches adds support for handling TPM2
>>> log when it is reported through ACPI TPM2 table, as
>>> described in latest TPM ACPI draft (Version 1.2, Revision 8,
>>> from February 27th, 2017).
>>>
>>> I've tested patch on x86 only - I do not have PPC64 system
>>> with TPM, and handling of endianness between tpm1_eventlog.c
>>> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
>>> be32_to_cpu() for all log fields on PPC64, while
>>> tpm2_eventlog.c uses log uses native endianness. If it
>>> is intentional, and PPC64 has TPM1 logs in big endian
>>
>> Yes, in case of ppc64, the tpm1 code logs are in big endian format.
>
> Thanks.  What about tpm2 logs?  Is first (specid) event in big endian
> format too, or no?

For TPM2 logs, all the events including the first one, are in little endian.

Sorry for delay in response.

Thanks & Regards,
    - Nayna

>
>>> while TPM2 logs in native endianness, then 3rd patch
>>> needs to be amended.
>>>
>>> Four patches split task of improving TPM2 support into following
>>> subtasks:
>>>
>>>
>>> 1. Add log start/length fields to TPM2 table
>>>
>>> This patch adds 1.2 rev 8 structures to TPM2 table, and
>>> modifies tpm_tis and tpm_crb to use
>>> offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
>>> to verify that TPM2 table is big enough.
>>>
>>>
>>> 2. Read TCG log from TPM2 table
>>>
>>> This patch modifies tpm_acpi code to read log start/length
>>> from TPM2 table similar way it does so from TCPA table.
>>>
>>>
>>> 3. Autodetect TCG event log version
>>>
>>> This patch modifies tpm1_eventlog to make decision whether
>>> to use TPM1 or TPM2 format based on log content, rather
>>> than from chip version: on x86 there is dozen of firmwares
>>> that use TPM1 log with TPM2 chip.
>>
>> Do you mean firmware support TPM1 log as only SHA1 log format and not
>> crypto agile log with only SHA1 ?
>
> Yes.  See f.e. 'TPM2 Preboot Event Log' paragraph in
> https://twobit.us/2016/05/tpm2-uefi-measurements-and-event-log/.
>
> If you think there is no need to support such obscure hardware (it does
> not support this year's draft of TPM2 ACPI spec as hardware is few years
> old, so it would matter only if boot loader would pass log address to
> the kernel, and currently there is no support for this in the kernel), I
> can move validation of header event to tpm2_eventlog.c, and simply
> reject any non-specid log with TPM2.
>                              Petr
>
>> Thanks & Regards,
>> - Nayna
>>
>>>
>>> Other part of the change is to validate content of specid
>>> event to make sure kernel does not crash when faced with
>>> specid event that claims there is 2^32-1 hashes in the
>>> event list.
>>>
>>>
>>> 4. Improve handling of TPM2 event logs
>>>
>>> Current code does not report any error when digest's hash
>>> is not listed in specid event, or if event reports 2^32-1
>>> digests (which is BIOS bug), or if event has more than
>>> 3 digests (that is kernel bug). Instead it will try to
>>> vmalloc() all available memory when event log is read by
>>> userspace application.
>>>
>>> This patch updates code so that it can handle arbitrary
>>> number of digests, as long as they are all described
>>> in specid event, and stops parsing as soon as any malformed
>>> event is detected.
>>>
>>>
>>> Let me know if there are any improvements I can make to
>>> this patch series.
>>>
>>> Thanks,
>>> Petr Vandrovec
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> tpmdd-devel mailing list
>>> tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
>>>
>>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

  parent reply	other threads:[~2017-04-03 18:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29  7:43 [PATCH 0/4] Add support for TPM2 log reported via ACPI table Petr Vandrovec
     [not found] ` <20170329074320.zcbuydd7iydaj3gr-WbvboCQVrrgDIl+Cyo8nDyLysJ1jNyTM@public.gmane.org>
2017-03-30  4:51   ` Nayna
     [not found]     ` <58DC8EBF.40700-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-03-30  8:13       ` Petr Vandrovec
     [not found]         ` <58DCBE41.3060507-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2017-03-31 14:43           ` Ken Goldman
2017-04-03 18:31           ` Nayna [this message]
2017-03-31  8:15   ` Jarkko Sakkinen
2017-03-31 18:39   ` Jarkko Sakkinen
     [not found]     ` <20170331183923.mmtggrj2bcybwajz-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-03-31 21:18       ` Petr Vandrovec
     [not found]         ` <58DEC79F.6000805-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2017-04-03 19:11           ` Jarkko Sakkinen

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=58E294FD.10504@linux.vnet.ibm.com \
    --to=nayna-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=petr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org \
    --cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /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).