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
