Re: [RFC PATCH v3 25/26] target/arm/kvm-rme: Add measurement log

[Jean-Philippe Brucker]

On Mon, Dec 02, 2024 at 10:58:01AM -0500, Stefan Berger wrote:
> 
> 
> On 11/26/24 11:21 AM, Jean-Philippe Brucker wrote:
> > On Tue, Nov 26, 2024 at 01:45:55PM +0000, Daniel P. Berrangé wrote:
> > > On Mon, Nov 25, 2024 at 05:23:44PM -0500, Stefan Berger wrote:
> > > > 
> > > > 
> > > > On 11/25/24 2:56 PM, Jean-Philippe Brucker wrote:
> > > > > Create an event log, in the format defined by Trusted Computing Group
> > > > > for TPM2. It contains information about the VMM, the Realm parameters,
> > > > > any data loaded into guest memory before boot and the initial vCPU
> > > > > state.
> > > > > 
> > > > > The guest can access this log from RAM and send it to a verifier, to
> > > > > help the verifier independently compute the Realm Initial Measurement,
> > > > > and check that the data we load into guest RAM is known-good images.
> > > > > Without this log, the verifier has to guess where everything is 
> > > > > loaded>
> > > > and in what order.
> > > > 
> > > > Typically these logs are backed by extensions of TPM PCRs and when you 
> > > > send
> > > > a log to a verifier you send a TPM quote along with it for the verifer 
> > > > to
> > > > replay the log and check the TPM quote. Also, early code in the 
> > > > firmware is
> > > > typically serving as a root of trust that starts the chain of 
> > > > measurements
> > > > of code and data, first measuring itself and then other parts of the
> > > > firmware before it jumps into the other parts. Now here you seem to just
> > > > have a log and no PCR extensions and therefore no quote over PCRs can be
> > > > used.
> > 
> > Indeed, in our case it's the trusted hypervisor (RMM) that provides the
> > equivalent to TPM quote and PCRs. In more details:
> > 
> > 1. QEMU loads images into guest RAM by calling KVM, which calls RMM.
> > 2. RMM calculates a hash of the image content, adds it to a rolling hash
> >     the "Realm Initial Measurement" (RIM), which I believe is equivalent to
> >     a PCR.
> 
> I am not familiar with RIM. A link to read more about it would be helpful.

The "Learn the architecture" documentation might be a good introduction
https://developer.arm.com/documentation/den0127/0200/Overview
In particular the part about Realm creation:
https://developer.arm.com/documentation/den0127/0200/Realm-management/Realm-creation-and-attestation

The RMM specification describes exactly how the RIM is calculated, but
is less palatable:
https://developer.arm.com/documentation/den0137/1-0rel0/?lang=en
A7.1.1 Realm Initial Measurement

More specialized resource are the attestation token documentation:
[1] https://datatracker.ietf.org/doc/html/draft-ffm-rats-cca-token-00
and CCA Security Model:
https://developer.arm.com/documentation/DEN0096/latest/

> 
> > 3. During remote attestation, the guest sends evidence containing this RIM
> >     signed by the root of trust, along with a signed token identifying the
> >     platform (hardware, firmware, RMM).
> 
> Is this a well known manufacturer key that one would expect for signature
> verification or is it locally created?

It comes from a well known manufacturer key, although the signing can be
delegated in some models (like in the current demos):

The hardware RoT creates a key pair for the RMM, which the RMM uses to
sign the RIM. The RoT then signs the RMM pubkey, using the well-known key
(see [1] 4.10 Token Binding).

> 
> > 4. The verifier checks the signature and the platform token, so it trusts
> >     the RMM and the RIM.
> > 
> > > > Then what prevents anyone from faking this log and presenting a
> > > > completely fake log to the verifier?
> > 
> > Absolutely, the verifier does not trust the content of the log, it only
> > uses the log as helper to try to reconstruct the RIM. For example a log
> > event says "I loaded image XYZ at address A", then the verifier searches
> > image XYZ in its database of known-good images, calculates the hash that
> > would result from loading that image at address A. Any malformed event in
> 
> Hopefully just calculating a hash over the image will do and the location an
> image was loaded to, like address A (relocation?), doesn't matter...

In this case it does matter because we don't trust the host VMM which
instructs RMM where to load the images. So we need to verify that the
image is in the correct location, otherwise the VM could be executing the
wrong part of the code, or using the wrong part of the data loaded into
RAM.

When loading an image the RMM hashes its content, then hashes a structure
that contains both the content hash and the address, and it is that hash
that is added to the RIM.

Thanks,
Jean