linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-integrity@vger.kernel.org
Cc: ross.philipson@oracle.com, dpsmith@apertussolutions.com,
	jarkko.sakkinen@linux.intel.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	luto@amacapital.net, trenchboot-devel@googlegroups.com
Subject: [RFC PATCH 0/4] Secure Launch early PCR extend support
Date: Sat, 31 Oct 2020 12:51:18 -0400	[thread overview]
Message-ID: <20201031165122.21539-1-dpsmith@apertussolutions.com> (raw)

This RFC is a break out of the prerequisite TPM functionality for the larger
Secure Launch capability. This TPM/PCR subset is in a separate smaller patch set
being sent as an RFC to get early feedback before the whole Secure Launch patch
set is resubmitted. This patch RFC, if accepted, will be part of the overall
Secure Launch patch set.

TPMs support numerous operations, the majority of which will never be used by
the Secure Launch feature in the compressed kernel. Given that, this RFC does
not seek to implement a TPM driver but merely enough logic for the PCR extend
operation with a reasonable reuse of the mainline TPM driver.

In this RFC is the early_pcr_extend functionality that is built from shared
headers with the mainline TPM driver for common definitions and TPM buffer
functionality. The early_pcr_extend balances the introduction of new logic to
communicate with the TPM without having to introduce unrelated hardware features
not already available under the compressed kernel. The target usage of
early_pcr_extend is to support DRTM capable hardware under Secure Launch.
Historically the authors have not encountered any DRTM capable hardware that
uses any other interface other than the TPM Interface Specification (TIS) FIFO
software interface. To minimize the impact to code size and avoid unnecessary
functionality in the compressed kernel, the early_pcr_extend provides a very
limited implementation of the FIFO interface necessary to set locality and carry
out the extend operation.

For the sake of completeness, a discussion on the proposed refactoring of the
mainline driver FIFO and TPM command handling for reuse in the compressed kernel
needs to be addressed. After reviewing the mainline TPM driver for a second
time, we have arrived at the conclusion that the driver is too entangled with
the mainline kernel functionality which makes refactoring highly impractical.
The following are a few examples of this entanglement. The mainline TPM driver
is built around the tpm_chip structure which uses definitions not available in
the compressed kernel. It is likely that bringing these definitions into the
compressed kernel purely to make the tpm_chip structure available, would be
found to be unacceptable. Therefore it would be necessary to create a compressed
kernel representation which would end up with a majority of tpm_chip structure
being stubbed out since very little of this abstraction is required for the one
TPM command that will be used. Another concern is that the mainline TPM driver
FIFO interface is heavily reliant on timers implemented with mainline kernel
jiffies for interacting with the TPM. The compressed kernel does not have access
to jiffies. In the compressed kernel, jiffies have not been initialized and
timers have not been started. Therefore the use of jiffies would have to be
abstracted out of the mainline TPM driver resulting in a significant refactoring
or borderline rewrite of the driver.

We believe that the approach we are presenting here should be satisfactory. We
feel it is clear that we are not trying to create a new TPM driver. We have
split up the TPM headers to be able to reuse almost all the needed definitions/
structures. In addition, we switched to using the mainline TPM driver's buffer
functions. The remaining code to do the extend is minimal and appropriate for
the compressed kernel environment.

Thank you,
Daniel P. Smith and Ross Philipson

Daniel P. Smith (4):
  tpm: Move TPM TIS definitions out of TIS core header
  tpm: Move core definitions and buffer management out of main TPM
    header
  tpm: Conditionally use static buffer in TPM buffer management
  x86: Add early PCR extend support for Secure Launch

 arch/x86/boot/compressed/Makefile           |   2 +
 arch/x86/boot/compressed/early_pcr_extend.c | 311 ++++++++++++++++++++++++++++
 arch/x86/boot/compressed/early_pcr_extend.h |  92 ++++++++
 drivers/char/tpm/tpm_tis_core.h             |  60 +-----
 drivers/char/tpm/tpm_tis_defs.h             |  81 ++++++++
 include/linux/tpm.h                         | 269 +-----------------------
 include/linux/tpm_buffer.h                  | 135 ++++++++++++
 include/linux/tpm_core.h                    | 185 +++++++++++++++++
 8 files changed, 809 insertions(+), 326 deletions(-)
 create mode 100644 arch/x86/boot/compressed/early_pcr_extend.c
 create mode 100644 arch/x86/boot/compressed/early_pcr_extend.h
 create mode 100644 drivers/char/tpm/tpm_tis_defs.h
 create mode 100644 include/linux/tpm_buffer.h
 create mode 100644 include/linux/tpm_core.h

-- 
2.11.0


             reply	other threads:[~2020-10-31 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-31 16:51 Daniel P. Smith [this message]
2020-10-31 16:51 ` [RFC PATCH 1/4] tpm: Move TPM TIS definitions out of TIS core header Daniel P. Smith
2020-10-31 16:51 ` [RFC PATCH 2/4] tpm: Move core definitions and buffer management out of main TPM header Daniel P. Smith
2020-11-02 12:09   ` Jarkko Sakkinen
2020-10-31 16:51 ` [RFC PATCH 3/4] tpm: Conditionally use static buffer in TPM buffer management Daniel P. Smith
2020-11-02 12:16   ` Jarkko Sakkinen
2020-10-31 16:51 ` [RFC PATCH 4/4] x86: Add early PCR extend support for Secure Launch Daniel P. Smith
2020-11-02 12:19   ` 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=20201031165122.21539-1-dpsmith@apertussolutions.com \
    --to=dpsmith@apertussolutions.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=trenchboot-devel@googlegroups.com \
    --cc=x86@kernel.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).