Re: [PATCH v8 14/15] x86: Secure Launch late initcall platform module

[Daniel P. Smith]

Hi Ard,

On 2/23/24 04:36, Ard Biesheuvel wrote:
> On Thu, 22 Feb 2024 at 14:58, Daniel P. Smith
> <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On 2/15/24 03:40, Ard Biesheuvel wrote:
> > > On Wed, 14 Feb 2024 at 23:32, Ross Philipson <ross.philipson@xxxxxxxxxx> wrote:
> > > > From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > > >
> > > > The Secure Launch platform module is a late init module. During the
> > > > init call, the TPM event log is read and measurements taken in the
> > > > early boot stub code are located. These measurements are extended
> > > > into the TPM PCRs using the mainline TPM kernel driver.
> > > >
> > > > The platform module also registers the securityfs nodes to allow
> > > > access to TXT register fields on Intel along with the fetching of
> > > > and writing events to the late launch TPM log.
> > > >
> > > > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: garnetgrimm <grimmg@xxxxxxxxxxxx>
> > > > Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx>
> > >
> > > There is an awful amount of code that executes between the point where
> > > the measurements are taken and the point where they are loaded into
> > > the PCRs. All of this code could subvert the boot flow and hide this
> > > fact, by replacing the actual taken measurement values with the known
> > > 'blessed' ones that will unseal the keys and/or phone home to do a
> > > successful remote attestation.
> >
> > To set context, in general the motivation to employ an RTM, Static or
> > Dynamic, integrity solution is to enable external platform validation,
> > aka attestation. These trust chains are constructed from the principle
> > of measure and execute that rely on the presence of a RoT for Storage
> > (RTS) and a RoT for Reporting (RTR). Under the TCG architecture adopted
> > by x86 vendors and now recently by Arm, those roles are fulfilled by the
> > TPM. With this context, lets layout the assumptive trusts being made here,
> >     1. The CPU GETSEC instruction functions correctly
> >     2. The IOMMU, and by extension the PMRs, functions correctly
> >     2. The ACM authentication process functions correctly
> >     3. The ACM functions correctly
> >     4. The TPM interactions function correctly
> >     5. The TPM functions correctly
> >
> > With this basis, let's explore your assertion here. The assertion breaks
> > down into two scenarios. The first is that the at-rest kernel binary is
> > corrupt, unintentionally (bug) or maliciously, either of which does not
> > matter for the situation. For the sake of simplicity, corruption of the
> > Linux kernel during loading or before the DRTM Event is considered an
> > equivalent to corruption of the kernel at-rest. The second is that the
> > kernel binary was corrupted in memory at some point after the DRTM event
> > occurs.
> >
> > For both scenarios, the ACM will correctly configure the IOMMU PMRs to
> > ensure the kernel can no longer be tampered with in memory. After which,
> > the ACM will then accurately measure the kernel (bzImage) and safely
> > store the measurement in the TPM.
> >
> > In the first scenario, the TPM will accurately report the kernel
> > measurement in the attestation. The attestation authority will be able
> > to detect if an invalid kernel was started and can take whatever
> > remediation actions it may employ.
> >
> > In the second scenario, any attempt to corrupt the binary after the ACM
> > has configured the IOMMU PMR will fail.
>
> This protects the memory image from external masters after the
> measurement has been taken.

It blocks access before the measurement is taken.

> So any external influences in the time window between taking the
> measurements and loading them into the PCRs are out of scope here, I
> guess?

Correct, as long as the assumption that the user configured the kernel 
to program the IOMMU correctly after gaining control. In early versions 
of this series the correct IOMMU configuration was enforced. This was 
changed due to objections that the user should be free to configure the 
system how they see fit, even if it results in an insecure system.

> Maybe it would help (or if I missed it - apologies) to include a
> threat model here. I suppose physical tampering is out of scope?

I can take a look at what other security capabilities have documented in 
this area and provide a similar level of explanation.

I would not say physical tampering is out, I would say that it is 
supported to the degree to which the TPM was designed to mitigate it.

> > > At the very least, this should be documented somewhere. And if at all
> > > possible, it should also be documented why this is ok, and to what
> > > extent it limits the provided guarantees compared to a true D-RTM boot
> > > where the early boot code measures straight into the TPMs before
> > > proceeding.
> >
> > I can add a rendition of the above into the existing section of the
> > documentation patch that already discusses separation of the measurement
> > from the TPM recording code. As to the limits it incurs on the DRTM
> > integrity, as explained above, I submit there are none.
>
> Thanks for the elaborate explananation. And yes, please document this
> with the changes.

Ack.

V/r,
Daniel