Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch

2021-01-19 Thread Daniel P. Smith
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
>> From: "Daniel P. Smith" 
>>
>> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
>> above the TPM hardware interface.
>>
>> Signed-off-by: Daniel P. Smith 
>> Signed-off-by: Ross Philipson 
> 
> This is way, way too PoC. I wonder why there is no RFC tag.
> 
> Please also read section 2 of
> 
> https://www.kernel.org/doc/html/v5.8/process/submitting-patches.html
> 
> You should leverage existing TPM code in a way or another. Refine it so
> that it scales for your purpose and then compile it into your thing
> (just include the necesary C-files with relative paths).
> 
> How it is now is never going to fly.
> 
> /Jarkko
> 

After attempts to engage in finding alternative approaches, it appears
that the only welcomed approach for sending measurements from the
compressed kernel would be a major rewrite of the mainline TPM driver to:

1. Abstract out the mainline kernel infrastructure that is used by the
driver

2. Find ways to introduce a minimal amount of the equivalent
infrastructure into the compressed kernel, to make the driver code
reusable within the compressed kernel.

This approach would exceed the scope of changes we want to introduce to
non-SecureLaunch code to enable direct DRTM launch for the Linux kernel.

After careful consideration and discussions with colleagues from the
trusted computing community, an alternative has been crafted. We aim to
submit a version 2 with the following approach:

1. SecureLaunch will take measurements in the compressed kernel as we do
in version 1, but instead of immediately sending them to the TPM, they
will be stored in the DRTM TPM event log.

2. When the SecureLaunch module in the mainline kernel comes on line, it
can send measurements to the TPM using the mainline TPM driver.

While it would be ideal to record measurements at the time they are
taken, the mainline kernel is measured alongside the compressed kernel
as a single measurement. This means the same measured entity stays in
control, prior to execution by any other entity within the system.

At a later date, if the TPM maintainers refactor the TPM driver for
reuse within the compressed kernel, then the sending of measurements can
be revisited.

For individuals and distributions that may prefer to record DRTM
measurements earlier, the TrenchBoot project will do its best to
maintain an external patch to provide that capability to a mainline LTS
kernel.

V/r,
Daniel P. Smith
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch

2020-09-29 Thread Jarkko Sakkinen
On Wed, Sep 30, 2020 at 06:19:57AM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> > TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> > and the latter will be getting maintenance under TB. While this is not
> > preferred, we had to weigh this versus trying to convince you and the
> > other TPM driver maintainers on a significant refactoring of the TPM
> > driver. It was elected for the reuse of a clean implementation that can
> > be replaced later if/when the TPM driver was refactored. When we
> > explained this during the RFC and it was not rejected, therefore we
> > carried it forward into this submission.
> 
> What does it anyway mean when you say "RFC was not rejected"? I don't
> get the semantics of that sentence. It probably neither was ack'd,
> right? I do not really care what happened with the RFC. All I can say
> is that in the current state this totally PoC from top to bottom.
> 
> > > How it is now is never going to fly.
> > 
> > We would gladly work with you and the other TPM maintainers on a
> > refactoring of the TPM driver to separate core logic into standalone
> > files that both the driver and the compressed kernel can share.
> 
> Yes, exactly. You have to refactor out the common parts. This is way too
> big patch to spend time on giving any more specific advice. Should be in
> way smaller chunks. For (almost) any possible, this is of unacceptable
   ^ " patch"
> size.
> 
> I think that it'd be best first to keep the common files in
> drivers/char/tpm and include them your code with relative paths in the
> Makefile. At least up until we have clear view what are the common
> parts.
> 
> You might also want to refactor drivers/char/tpm/tpm.h and include/linux
> TPM headers to move more stuff into include/linux.
> 
> If you are expecting a quick upstreaming process, please do not. This
> will take considerable amount of time to get right.

/Jarkko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch

2020-09-29 Thread Jarkko Sakkinen
On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> and the latter will be getting maintenance under TB. While this is not
> preferred, we had to weigh this versus trying to convince you and the
> other TPM driver maintainers on a significant refactoring of the TPM
> driver. It was elected for the reuse of a clean implementation that can
> be replaced later if/when the TPM driver was refactored. When we
> explained this during the RFC and it was not rejected, therefore we
> carried it forward into this submission.

What does it anyway mean when you say "RFC was not rejected"? I don't
get the semantics of that sentence. It probably neither was ack'd,
right? I do not really care what happened with the RFC. All I can say
is that in the current state this totally PoC from top to bottom.

> > How it is now is never going to fly.
> 
> We would gladly work with you and the other TPM maintainers on a
> refactoring of the TPM driver to separate core logic into standalone
> files that both the driver and the compressed kernel can share.

Yes, exactly. You have to refactor out the common parts. This is way too
big patch to spend time on giving any more specific advice. Should be in
way smaller chunks. For (almost) any possible, this is of unacceptable
size.

I think that it'd be best first to keep the common files in
drivers/char/tpm and include them your code with relative paths in the
Makefile. At least up until we have clear view what are the common
parts.

You might also want to refactor drivers/char/tpm/tpm.h and include/linux
TPM headers to move more stuff into include/linux.

If you are expecting a quick upstreaming process, please do not. This
will take considerable amount of time to get right.

/Jarkko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch

2020-09-29 Thread Daniel P. Smith
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
>> From: "Daniel P. Smith" 
>>
>> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
>> above the TPM hardware interface.
>>
>> Signed-off-by: Daniel P. Smith 
>> Signed-off-by: Ross Philipson 
> 
> This is way, way too PoC. I wonder why there is no RFC tag.

An RFC was sent back in March and we incorporated the feedback we
received at that time.

> Please also read section 2 of
> 
> https://www.kernel.org/doc/html/v5.8/process/submitting-patches.html
> 
> You should leverage existing TPM code in a way or another. Refine it so
> that it scales for your purpose and then compile it into your thing
> (just include the necesary C-files with relative paths).

We explained during the RFC phase that we took a fair bit of time and a
very hard look to see if we could #include sections out the TPM driver
but as it is today none of the TPM driver's c files can be included
outside of the mainline kernel. If you look at the early boot stub for
the compressed kernel you will see that we are interacting with the TPM
as the first thing upon leaving the assembly world and entering C. Since
we weren't going to be able to get the mainline TPM driver plucked down,
we could either 1.) borrow an implementation from a colleague that
provides the minimum command strings hard coded in C macros to send
measurements to the TPM or 2.) reuse the TPM implementation we wrote for
TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
and the latter will be getting maintenance under TB. While this is not
preferred, we had to weigh this versus trying to convince you and the
other TPM driver maintainers on a significant refactoring of the TPM
driver. It was elected for the reuse of a clean implementation that can
be replaced later if/when the TPM driver was refactored. When we
explained this during the RFC and it was not rejected, therefore we
carried it forward into this submission.


> How it is now is never going to fly.

We would gladly work with you and the other TPM maintainers on a
refactoring of the TPM driver to separate core logic into standalone
files that both the driver and the compressed kernel can share.

> /Jarkko
> 


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch

2020-09-24 Thread Jarkko Sakkinen
On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
> From: "Daniel P. Smith" 
> 
> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
> above the TPM hardware interface.
> 
> Signed-off-by: Daniel P. Smith 
> Signed-off-by: Ross Philipson 

This is way, way too PoC. I wonder why there is no RFC tag.

Please also read section 2 of

https://www.kernel.org/doc/html/v5.8/process/submitting-patches.html

You should leverage existing TPM code in a way or another. Refine it so
that it scales for your purpose and then compile it into your thing
(just include the necesary C-files with relative paths).

How it is now is never going to fly.

/Jarkko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch

2020-09-24 Thread Ross Philipson
From: "Daniel P. Smith" 

This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
above the TPM hardware interface.

Signed-off-by: Daniel P. Smith 
Signed-off-by: Ross Philipson 
---
 arch/x86/boot/compressed/Makefile |   3 +-
 arch/x86/boot/compressed/tpm/tpm1.h   | 112 
 arch/x86/boot/compressed/tpm/tpm1_cmds.c  |  99 ++
 arch/x86/boot/compressed/tpm/tpm2.h   |  89 
 arch/x86/boot/compressed/tpm/tpm2_auth.c  |  44 
 arch/x86/boot/compressed/tpm/tpm2_auth.h  |  21 
 arch/x86/boot/compressed/tpm/tpm2_cmds.c  | 145 ++
 arch/x86/boot/compressed/tpm/tpm2_constants.h |  66 
 8 files changed, 578 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/boot/compressed/tpm/tpm1.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm1_cmds.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_auth.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_auth.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_cmds.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_constants.h

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 5515afa..a4308d5 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -100,7 +100,8 @@ vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o
 vmlinux-objs-$(CONFIG_SECURE_LAUNCH_SHA256) += $(obj)/early_sha256.o
 vmlinux-objs-$(CONFIG_SECURE_LAUNCH_SHA512) += $(obj)/early_sha512.o
 vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/tpm/tpmio.o 
$(obj)/tpm/tpm_buff.o \
-   $(obj)/tpm/tis.o $(obj)/tpm/crb.o
+   $(obj)/tpm/tis.o $(obj)/tpm/crb.o $(obj)/tpm/tpm1_cmds.o \
+   $(obj)/tpm/tpm2_cmds.o $(obj)/tpm/tpm2_auth.o
 
 # The compressed kernel is built with -fPIC/-fPIE so that a boot loader
 # can place it anywhere in memory and it will still run. However, since
diff --git a/arch/x86/boot/compressed/tpm/tpm1.h 
b/arch/x86/boot/compressed/tpm/tpm1.h
new file mode 100644
index 000..498fa45
--- /dev/null
+++ b/arch/x86/boot/compressed/tpm/tpm1.h
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Apertus Solutions, LLC
+ *
+ * Author(s):
+ *  Daniel P. Smith 
+ *
+ * The definitions in this header are extracted from the Trusted Computing
+ * Group's "TPM Main Specification", Parts 1-3.
+ *
+ */
+
+#ifndef _TPM1_H
+#define _TPM1_H
+
+#include "tpm.h"
+
+/* Section 2.2.3 */
+#define TPM_AUTH_DATA_USAGE u8
+#define TPM_PAYLOAD_TYPE u8
+#define TPM_VERSION_BYTE u8
+#define TPM_TAG u16
+#define TPM_PROTOCOL_ID u16
+#define TPM_STARTUP_TYPE u16
+#define TPM_ENC_SCHEME u16
+#define TPM_SIG_SCHEME u16
+#define TPM_MIGRATE_SCHEME u16
+#define TPM_PHYSICAL_PRESENCE u16
+#define TPM_ENTITY_TYPE u16
+#define TPM_KEY_USAGE u16
+#define TPM_EK_TYPE u16
+#define TPM_STRUCTURE_TAG u16
+#define TPM_PLATFORM_SPECIFIC u16
+#define TPM_COMMAND_CODE u32
+#define TPM_CAPABILITY_AREA u32
+#define TPM_KEY_FLAGS u32
+#define TPM_ALGORITHM_ID u32
+#define TPM_MODIFIER_INDICATOR u32
+#define TPM_ACTUAL_COUNT u32
+#define TPM_TRANSPORT_ATTRIBUTES u32
+#define TPM_AUTHHANDLE u32
+#define TPM_DIRINDEX u32
+#define TPM_KEY_HANDLE u32
+#define TPM_PCRINDEX u32
+#define TPM_RESULT u32
+#define TPM_RESOURCE_TYPE u32
+#define TPM_KEY_CONTROL u32
+#define TPM_NV_INDEX u32 The
+#define TPM_FAMILY_ID u32
+#define TPM_FAMILY_VERIFICATION u32
+#define TPM_STARTUP_EFFECTS u32
+#define TPM_SYM_MODE u32
+#define TPM_FAMILY_FLAGS u32
+#define TPM_DELEGATE_INDEX u32
+#define TPM_CMK_DELEGATE u32
+#define TPM_COUNT_ID u32
+#define TPM_REDIT_COMMAND u32
+#define TPM_TRANSHANDLE u32
+#define TPM_HANDLE u32
+#define TPM_FAMILY_OPERATION u32
+
+/* Section 6 */
+#define TPM_TAG_RQU_COMMAND0x00C1
+#define TPM_TAG_RQU_AUTH1_COMMAND  0x00C2
+#define TPM_TAG_RQU_AUTH2_COMMAND  0x00C3
+#define TPM_TAG_RSP_COMMAND0x00C4
+#define TPM_TAG_RSP_AUTH1_COMMAND  0x00C5
+#define TPM_TAG_RSP_AUTH2_COMMAND  0x00C6
+
+/* Section 16 */
+#define TPM_SUCCESS 0x0
+
+/* Section 17 */
+#define TPM_ORD_EXTEND 0x0014
+
+#define SHA1_DIGEST_SIZE 20
+
+/* Section 5.4 */
+struct tpm_sha1_digest {
+   u8 digest[SHA1_DIGEST_SIZE];
+};
+struct tpm_digest {
+   TPM_PCRINDEX pcr;
+   union {
+   struct tpm_sha1_digest sha1;
+   } digest;
+};
+
+#define TPM_DIGEST struct tpm_sha1_digest
+#define TPM_CHOSENID_HASH  TPM_DIGEST
+#define TPM_COMPOSITE_HASH TPM_DIGEST
+#define TPM_DIRVALUE   TPM_DIGEST
+#define TPM_HMAC   TPM_DIGEST
+#define TPM_PCRVALUE   TPM_DIGEST
+#define TPM_AUDITDIGESTTPM_DIGEST
+#define TPM_DAA_TPM_SEED   TPM_DIGEST
+#define TPM_DAA_CONTEXT_SEED   TPM_DIGEST
+
+struct tpm_extend_cmd {
+   TPM_PCRINDEX pcr_num;
+   TPM_DIGEST digest;
+};
+
+struct