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

[Daniel P. Smith]

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 
>> ---
>>  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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

[Jason Gunthorpe]

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 
> ---
>  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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

[Ross Philipson]

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 
---
 drivers/char/tpm/tpm-chip.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index ddaeceb..ce0a3b7 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "tpm.h"
 
 DEFINE_IDR(dev_nums_idr);
@@ -34,12 +35,18 @@
 
 static int tpm_request_locality(struct tpm_chip *chip)
 {
+   int locality;
int rc;
 
if (!chip->ops->request_locality)
return 0;
 
-   rc = chip->ops->request_locality(chip, 0);
+   if (slaunch_get_flags() & SL_FLAG_ACTIVE)
+   locality = 2;
+   else
+   locality = 0;
+
+   rc = chip->ops->request_locality(chip, locality);
if (rc < 0)
return rc;
 
-- 
1.8.3.1

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