qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Berger
Subject: Re: [RFC PATCH v3 25/26] target/arm/kvm-rme: Add measurement log
Date: Mon, 2 Dec 2024 10:58:01 -0500
User-agent: Mozilla Thunderbird



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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]