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

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

On 12/5/24 7:33 AM, Jean-Philippe Brucker wrote:
> 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/

Thanks for the links. I will have a look at them when I have time.

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

You should mention in the commit message that the log will be signed and 
user space can get the signature over the log from some filesystem or so.

    Stefan