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@xxxxxxxxxx> >> --- >> 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
