Re: [RFC PATCH 0/4] Alternative TPM patches for Trenchboot

["Daniel P. Smith" <dpsmith@apertussolutions.com>]

On 11/2/24 14:00, Jarkko Sakkinen wrote:
> On Sat Nov 2, 2024 at 5:22 PM EET, Jarkko Sakkinen wrote:
>> It is not really my problem but I'm also wondering how the
>> initialization order is managed. What if e.g. IMA happens to
>> initialize before slmodule?
> 
> The first obvious observation from Trenchboot implementation is that it
> is 9/10 times worst idea ever to have splitted root of trust. Here it
> is realized by an LKM for slmodule.

First, there is no conflict between IMA and slmodule. With your change 
to make locality switching a one shot, the only issue would be if IMA 
were to run first and issue a locality switch to Locality 0, thus 
blocking slmodule from switching to Locality 2. As for PCR usage, IMA 
uses the SRTM PCRs, which are completely accessible under Locality 2.

The RoT for DRTM is the CPU/microcode, and that is not split. I am going 
to assume that you are speaking about the delay between the time of 
collecting measurement to the time of storing measurement? As a 
refresher, an RTM trust chain is constructed using the transitive 
trust[1] process. As noted in the definition, the Linux kernel in this 
case is considered a group of functions that were all evaluated and 
considered functions to be equally part of the TCB. This means you are 
trusting actions at time interval M equally to an action taken at time 
interval N. If one attempts to construct an argument that claims this is 
invalid, that would mean all RTM trust chains constructed in this manner 
are invalidated, including SRTM aka SecureBoot. This means as long as 
the measurements are recorded before the TCB is extended again, then it 
does not matter if it is done at time M or time N.

Bringing this back to SecureLaunch, there would only be an issue if 
slmodule could be built as an external loadable module, thus not being 
part of the "group of functions" measured and executed by the SINIT ACM. 
AFAICT, slmodule can only either be compiled in or out, not as a 
loadable module. If there is a path we missed that allows it to be built 
as a loadable module, then that needs correcting. Due to this comment, I 
went testing KCONFIG options and could not come up with a way for this 
to occur. I did see that we probably should change CONFIG_SECURE_LAUNCH 
dependency from TCG_TPM to TPM_TIS and TCG_CRB. Just to avoid an invalid 
configuration where the necessary interfaces were not present, leading 
to triggering a TXT reset of the platform.

[1] Transitive trust (TCG D-RTM Architecture - Version 1.0.0)
Also known as "inductive trust." In this process, the Root of Trust 
gives a trustworthy description of a second group of functions. Based on 
this description, an interested entity can determine the trust it is to 
place in this second group of functions. If the interested entity 
determines that the trust level of the second group of functions is 
acceptable, the trust boundary is extended from the Root of Trust to
include the second group of functions. In this case, the process can be
iterated. The second group of functions can give a trustworthy 
description of the third group of functions, etc. Transitive trust is 
used to provide a trustworthy description of platform characteristics.

> So based on that usually a literal and unquestionable truth, when it
> comes to securing platforms, the next question is how to make a single
> atomic root of trust for Trenchboot.
As mentioned above, there is no split currently.

> There is really only one answer I think of for this it to make slmodule
> part of the tpm_tis_core and also init order will be sorted out.

Only if your assertion that it was split, which it is not.

> I'll describe the steps forward.

Honestly, a better path forward would be to revisit the issue that is
driving most of that logic existing, which is the lack of a TPM
interface code in the setup kernel. As a reminder, this issue is due to
the TPM maintainers position that the only TPM code in the kernel can be
the mainline driver. Which, unless something has changed, is impossible
to compile into the setup kernel due to its use of mainline kernel
constructs not present in the setup kernel.

v/r,
dps