Re: [tpmdd-devel] [PATCH 0/4] Add support for TPM2 log reported via ACPI table
On Fri, Mar 31, 2017 at 02:18:23PM -0700, Petr Vandrovec wrote: > Jarkko Sakkinen wrote: > > On Wed, Mar 29, 2017 at 12:43:20AM -0700, 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 > > > while TPM2 logs in native endianness, then 3rd patch > > > needs to be amended. > > > > > > Four patches split task of improving TPM2 support into following > > > subtasks: > > > > This cover letter is a bit chaotic. A cover letter should give an > > understandable description of the what is done. Now you have a 2nd > > version of commit messages here. This looks confusing. > > Hi Jarkko, > > sorry about that. I wanted to provide additional details in the cover > letter. As far as understandable description, it is more or less covered in > first paragraph. Would this summary work for you: > > This series 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). > > Second half of the series then improves support for TPM2 log parsing, so > kernel does not crash when firmware provides TPM log in different format > than 'Spec ID Event03', or if it uses Event03 format with more than 3 > hashes. > > > Thanks, > Petr Great, thank you. I'll look into this in more detail after we are done with 4.12. /Jarkko -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [PATCH 0/4] Add support for TPM2 log reported via ACPI table
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@lists.sourceforge.net >>> 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 tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [PATCH 0/4] Add support for TPM2 log reported via ACPI table
Oh there it was. /Jarkko On Wed, Mar 29, 2017 at 12:43:20AM -0700, 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 > 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. > > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [tpmdd-devel] [PATCH 0/4] Add support for TPM2 log reported via ACPI table
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. > 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 ? 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@lists.sourceforge.net > 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 tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
[tpmdd-devel] [PATCH 0/4] Add support for TPM2 log reported via ACPI table
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 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. 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
