From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nayna Subject: Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table Date: Tue, 4 Apr 2017 00:01:25 +0530 Message-ID: <58E294FD.10504@linux.vnet.ibm.com> References: <20170329074320.zcbuydd7iydaj3gr@petr-dev3.eng.vmware.com> <58DC8EBF.40700@linux.vnet.ibm.com> <58DCBE41.3060507@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <58DCBE41.3060507-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Petr Vandrovec Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net 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