linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.microsoft.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Peter Huewe <peterhuewe@gmx.de>, Ard Biesheuvel <ardb@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Petr Vandrovec <petr@vmware.com>,
	Nayna Jain <nayna@linux.ibm.com>,
	Thirupathaiah Annapureddy <thiruan@microsoft.com>,
	linux-integrity@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] tpm: Require that all digests are present in TCG_PCR_EVENT2 structures
Date: Mon, 15 Jun 2020 18:25:04 -0500	[thread overview]
Message-ID: <20200615232504.1848159-1-tyhicks@linux.microsoft.com> (raw)

Require that the TCG_PCR_EVENT2.digests.count value strictly matches the
value of TCG_EfiSpecIdEvent.numberOfAlgorithms in the event field of the
TCG_PCClientPCREvent event log header. Also require that
TCG_EfiSpecIdEvent.numberOfAlgorithms is non-zero.

The TCG PC Client Platform Firmware Profile Specification section 9.1
(Family "2.0", Level 00 Revision 1.04) states:

 For each Hash algorithm enumerated in the TCG_PCClientPCREvent entry,
 there SHALL be a corresponding digest in all TCG_PCR_EVENT2 structures.
 Note: This includes EV_NO_ACTION events which do not extend the PCR.

Section 9.4.5.1 provides this description of
TCG_EfiSpecIdEvent.numberOfAlgorithms:

 The number of Hash algorithms in the digestSizes field. This field MUST
 be set to a value of 0x01 or greater.

Enforce these restrictions, as required by the above specification, in
order to better identify and ignore invalid sequences of bytes at the
end of an otherwise valid TPM2 event log. Firmware doesn't always have
the means necessary to inform the kernel of the actual event log size so
the kernel's event log parsing code should be stringent when parsing the
event log for resiliency against firmware bugs. This is true, for
example, when firmware passes the event log to the kernel via a reserved
memory region described in device tree.

Prior to this patch, a single bit set in the offset corresponding to
either the TCG_PCR_EVENT2.eventType or TCG_PCR_EVENT2.eventSize fields,
after the last valid event log entry, could confuse the parser into
thinking that an additional entry is present in the event log. This
patch raises the bar on how difficult it is for stale memory to confuse
the kernel's event log parser but there's still a reliance on firmware
to properly initialize the remainder of the memory region reserved for
the event log as the parser cannot be expected to detect a stale but
otherwise properly formatted firmware event log entry.

Fixes: fd5c78694f3f ("tpm: fix handling of the TPM 2.0 event logs")
Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 include/linux/tpm_eventlog.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index 4f8c90c93c29..d83eb9fd5614 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -201,7 +201,7 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
 	efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
 
 	/* Check if event is malformed. */
-	if (count > efispecid->num_algs) {
+	if (!efispecid->num_algs || count != efispecid->num_algs) {
 		size = 0;
 		goto out;
 	}
-- 
2.25.1


             reply	other threads:[~2020-06-15 23:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15 23:25 Tyler Hicks [this message]
2020-06-16  9:08 ` [PATCH] tpm: Require that all digests are present in TCG_PCR_EVENT2 structures Ard Biesheuvel
2020-06-16 15:22   ` Tyler Hicks
2020-06-17 23:09   ` Jarkko Sakkinen
2020-06-30 18:33     ` Tyler Hicks
2020-07-02 23:57       ` Jarkko Sakkinen
2020-07-09 22:58         ` Tyler Hicks
2020-07-10 11:02           ` Jarkko Sakkinen
2020-06-30 18:53   ` Peter Jones
2020-06-30 19:10     ` Ard Biesheuvel
2020-06-30 19:23     ` Tyler Hicks
2020-06-30 19:48       ` Peter Jones

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=20200615232504.1848159-1-tyhicks@linux.microsoft.com \
    --to=tyhicks@linux.microsoft.com \
    --cc=ardb@kernel.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nayna@linux.ibm.com \
    --cc=peterhuewe@gmx.de \
    --cc=petr@vmware.com \
    --cc=thiruan@microsoft.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).