lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 19 Jan 2021 19:33:52 -0500
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Ross Philipson <ross.philipson@...cle.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        iommu@...ts.linux-foundation.org, linux-integrity@...r.kernel.org,
        linux-doc@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, luto@...capital.net,
        trenchboot-devel@...glegroups.com
Subject: Re: [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 interface support for
 Secure Launch

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" <dpsmith@...rtussolutions.com>
>>
>> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
>> above the TPM hardware interface.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@...rtussolutions.com>
>> Signed-off-by: Ross Philipson <ross.philipson@...cle.com>
> 
> 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

Powered by blists - more mailing lists