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? >> 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 >> [email protected] >> 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 _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
