linux-kernel - Re: [PATCH v4 14/14] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Aug 2021 15:45:21 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Jason Gunthorpe <jgg@...pe.ca>,
        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,
        kanth.ghatraju@...cle.com, trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v4 14/14] tpm: Allow locality 2 to be set when
 initializing the TPM for Secure Launch

On 8/27/21 9:30 AM, Jason Gunthorpe wrote:
> On Fri, Aug 27, 2021 at 09:28:37AM -0400, Ross Philipson wrote:
>> The Secure Launch MLE environment uses PCRs that are only accessible from
>> the DRTM locality 2. By default the TPM drivers always initialize the
>> locality to 0. When a Secure Launch is in progress, initialize the
>> locality to 2.
>>
>> Signed-off-by: Ross Philipson <ross.philipson@...cle.com>
>> ---
>>  drivers/char/tpm/tpm-chip.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> Global state like this seems quite dangerous, shouldn't the locality
> be selected based on the PCR being accessed, or passed down from
> higher up in the call chain?
> 
> Jason
> 

Hey Jason,

While locality does control which PCRs are accessible, it is meant to
reflect what component that a TPM command is originating. To quote the
TCG Spec, "“Locality” is an assertion to the TPM that a command’s source
is associated with a particular component. Locality can be thought of as
a hardware-based authorization."

Thus when the SRTM chain, to include the Static OS, is in control, the
hardware is required to restrict access to only Locality 0. Once a
Dynamic Launch has occurred, the hardware grants access to Locality 1
and 2. Again to refer to the TCG spec, the definition of Locality 2 is,
the "Dynamically Launched OS (Dynamic OS) “runtime” environment".

When Linux is started from the SRTM, it is correct for the TPM driver to
set the locality to Locality 0 to denote that the source is the Static
OS. Now when Linux is started from the DRTM, the TPM driver should set
the locality to Locality 2 to denote that it is the "runtime" Dynamic
OS. As for the differences in access, with Locality 0 Linux (being the
Static OS) is restricted to the Static PCRs (0-15), the Debug PCR (16),
and the Application PCR (23). Whereas with Locality 2 Linux now being
the Dynamic OS will have access to all PCRs.

To summarize, TPM locality really is a global state that reflects the
component in control of the platform. Considering the definition of
locality, setting the locality to Locality 0 is saying that the Static
Environment is now in control. Doing so after the Dynamic Environment
has started would be an inaccurate setting of the platform state. The
correct time at which the locality should change back to Locality 0 is
after the Dynamic Environment has been exited. On Intel this can be done
by invoking the instruction GETSEC[SEXIT]. It should be noted that
Secure Launch adds the call to the GETSEC[SEXIT] instruction in the
kexec, reboot, and shutdown paths.

v/r,
dps