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. 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). 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 the log causes the hash to diverge from the trusted RIM value, and causes an attestation error. > In addition, a measurement log is just one of the interesting features > that a TPM provides to OS. The other TPM features are still relevant > and useful to confidential VMs. > > As a high level goal I think we should be aiming to make it possible for > users to move their existing VM workloads from non-confidentail to > confidential environments, simply as a choice at deployment time. To make > this as practical as possible, confidential VMs need to be aiming to > match non-confidential VM features where ever it is practical to do so. > Users & vendors should not need to build & carry around 2 sets of disk > images - one setup for confidential and one setup for non-confidential. > Following existing standards will reduce the work both for OS developers, > app developers and users alike, to adopt the CVM world. > > IOW, this is a long winded way of saying that we should be looking to > provide a complete *standards compliant*, trusted TPM implementation to > confidential VMs, not providing a cherry-picked selection of a few > TPM-like features. > > On the x86 side of things, the route to providing a trusted TPM is via > SVSM, both for SNP and TDX. Microsoft's recently open sources openhcl > similarly provides a st > > I don't know so much about RME. Is providing a trusted TPM a job for > the RMM ? Not directly, but I've heard of at least two options that are being actively worked on: * running payloads like SVSM and openhcl that emulate a TPM. In RMM 1.1 there is a concept of "planes" that enables this. * having edk2 in the VM provide a "fTPM". I'm less familiar with these, but I think both need to connect the virtual TPM to the root of trust by performing remote attestation via RMM (?). So the problem of reconstructing a RIM on the verifier side remains, even if it's not done by the application. In addition I'm wondering about lighter, container-like workloads, which will want to boot quickly and run the bare minimum software, and where edk2 or SVSM seems superfluous. Maybe people will want to tailor those workloads and avoid the extra layer? Thanks, Jean
