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

[Stefan Berger <stefanb@linux.ibm.com>]

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.

> 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?

> 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...