I have been working on the software that manages confidential VMs on ARM in QMU and Cloud
Hypervisor, and that got me wondering how we compute the reference values that correspond
to a given VM and other check during a destination.
I'd like to give a quick overview of the findings of how and present a tool that allows
to compute those values.
This is the kind of software start that we were considering, much you talked about it
during yesterday's computational computing session.
On the top left, the VM and creates and manages the VM, the hypervisor, the
KVN, tells to its trusted counterpart, to install the VM, then ARMN tells the guest,
which contains at least an application on the kernel, but can contain a lot of different
components, like EFI firmware, bootloader, Paravizer, containers, anything you can
think of.
Each of these components can request a destination at one time from a very file.
The atestation first should look familiar, initially we provide a very file with reference
values.
During a destination, the verifyer sends a challenge, announced to the atester, then ARMN
and hardware creates an atestation token, a good and sign it, and then the verifyer checks
those signature and compares the values contained in the atestation token against its
reference values if they match its sends a positive result.
In the right, the atestation token is played between information about the platform and information
about the code and data that goes into the RAM, which is what I will be focusing on.
I would like to say the RAM is what we call the trusted environment on the right here.
So the question is, when we create the VM, I remember everything that goes into the RAM,
so it starts by hashing the VM parameters to create the initial measurement, the RAM, and whenever
we load an image into the RAM, it touches each page of that image and add it to the RAM.
It also has the initial vcp registers, so the order of operation is crucial because each
operation takes a remas input, there are also runtime measurements that components within
the RAM can extend the hash some images, the loading for example, and add that hash to the
runtime measurement.
The question is, how do we compute this frame as a reference value provider?
The easy way is to just run the whole payload once on a machine request and extract the
rim that you can then probably run it to the very fire.
In general, that is impractical and it won't be feasible because you won't have access to
the machine that can be paid off, so we've created this two CC error measurements, it
says it's another the raise and project.
You pass it the images that you load into the RAM and the command land parameters of your
VMM and it outputs a reference value that you can provision your very fire with, the main complexity
in calculating the rim, is that there is no standout on VMHPM and we'll have the own way
of loading a payload and we'll have the own memory map and the own iacumat, because we want
to measure the firmware tables that describe the platform to the RAM, we need to know exactly
that memory map, so the two defines a canonical loading order for the operations that went into
the rim calculation and it also describes a couple of virtual platforms, so if the VMM follows
that specification then we can generate the firmware tables, measure them and we'll end up with
the same, the same measurements, and a possible problem with pre computing that in this way
is that it doesn't scale well for each possible configuration you need to generate a RAM, so
you can with a straight even with a straight VM specification, it could become a manageable
if you want to add less of different parameters, so we've explored a way to do it dynamically instead
of provisioning the very fire with the RAM reference value, we can equip it with the ability to
compute the rim during attestation, the way it works is when when creating the VM,
the VM and also creates a log of anything that went into computing the rim, and the log is
unmergeed and it's passed through the the firmware table, and during attestation the attestance
this log along the attestation token, the very fire then attempts to compute the rim
by passing the log, it's important to note that the log is untrusted but images that we use to compute
the rim are trusted, and the parameters that are in the log can be checked against the
policy at reloading to the very far, if the very fire manager is to come up with the same ring
as the one in the attestation token, when it comes to the ability result and it comes to
cache the rim as a reference value for later, I've been completing the very fire and the
relying party here, so we have a prototype of this based on the keyboard code that
marked your mentioned yesterday, so the keyboard guard is the relying party and talks to a
very fire to get some part of the attestation to, for example, get the platform token,
and then the keyboard guard itself can compute the rim at one time, so I presented three options
for completing the run token and our two allows to explain and with two of them,
it's proof of concept at the moment and we like input from possible users about what we should
be focusing on next, there are a few things to standardize in particular the protocol that we use to
send along the log alongside the attestation token, that will be needed as well for runtime
environments which can be augmented, run domain by components running in the run, so we do need
describing what the equation is going to be in the, most of it and there are some links in the slides,
we can talk about, you can recreate something, you can learn a bit on a lot of bits and
it's all based on Q and Q and the armfast model, so it's easy to run a domain, sorry
it's the hobby is the log for the rim it's very small but so we only store hashes of the images
that went in there, so it's a few hashes and a couple of parameters not much, so I've been wondering
if instead of pre-generating the firmware tables we could also pass the whole firmware table in
the log, so the verifyer can check the content instead of us generating it, so that would be a bit bigger
but not too much, so I'm not sure if instead of the first building design for these cases like
my A to the hand, I love the arm, initial work is being designed to serve the size staff, so arm has got
more of the size pieces, so how well does this map to IoT, well for the moment we've been focusing
on cloud computing, so this is all based on demo that represent a cloud work, but the tool is generic
it's a very small library that you can use for anything new, so the principle of launching a VM on
can be derived to IoT as something I'd like to explain
like a lot of issues, so the question is why do you want to use it, and how about IoT?
Right, the question is to we plan to use the TCG TPM log and where is the route of trust in there,
so we are basing the log format on the TCG TPM to the moment, we're just adding a few
event types in there, and the route of trust in the arm CCA architecture is based on the hardware
security chip, and that's the chip that signs the attestation token that goes out to the
very fire, so all the measurements which are performed by the RMM are changed to this hardware
with the trust, and so your questions?
It's the only thing that we trust is the final calculation of the ring, so unless we arrive to this
ring value, we're not trusting anything in between, so the log and the log only describe the
different step that one is duplicating that end.
For the hosting structure, how are we given any thought in the live patching on the host?
Not me in particular, but I know there is some effort to modify or to update the firmware and
the kernel at one time, so I don't know, at the moment it's based on QM or the
USB signal, you guys want to ask why, so I just allow, of course, you can see if anything is
finished, it's helpful.
use the attestated TLS protocol when the logo is small. I don't quite see where that fits in with the line.
Right, that's right.
Yes, no, no, there is no problem with that, it's just adding.
So we send the attestation token raw as a single payload and we need to add some fields in there to store the logo and that's all I mean.
Yeah, you have to know.
Thank you.