So, hi, welcome to our talk.
We will give an update on the Coconut SDSVSM project.
We have a quick introduction on confidential virtualization.
We want to take out the hypervisor and the cloud provider of the things that we need to trust.
And rely on the hyper platform to provide confidentiality for the virtual machine.
This comes with a little problem.
Usually the hypervisor is emulating devices and providing services to the guests,
but it can no longer do because we don't trust it anymore.
So, as a solution to this, we need an execution environment that we can put these things.
And for example, on AMD, we have the term of the SDSM,
the secure VM service module.
And it runs inside of the TCP of the CVM.
It's isolated from the hypervisor and the guest.
And this is very useful.
For example, providing a virtual TPM device,
or helping with storing AFI variables as a migration helper and a lot of other things.
Okay, so Coconut SDSM is the implementation of such a service module.
We've got to start it out for AMD, Surface and P,
but we're working on generalizing it and support for Intel, TDXs on the way.
Currently we support pure and new hypervient vanadium master hypervises.
It's written in Rust.
So I've been 2002, a partialized in the MIT license here.
Currently, main feature provides a virtual TPM device to the guests.
And right now, we're still relying on an enlightened operating system,
but the parameterizer is on the program.
So, how does it look like?
Yeah, Coconut comes packaged as an IGVM file.
This is a file format that specifies the initial state of the guest.
So memory layout and content and registers.
It makes it easy because you have that file.
You can easily calculate initial launch measurement.
This gets loaded and everything is measured into the initial launch measurement,
which is then later part of the attestation report
that you can request and to verify by remote attestation
that we're running what we're expecting to run.
Yeah, and the S&P provides this feature called PMPL.
So that's a privilege mechanism to isolate the SBSM from the guest operating system.
Yeah, it launches, first it's an SBSM is launched,
then it launches the OVMF, which in turn then puts the Linux OS.
Yeah, we provide TPM device to the guest.
This is TPM is a femoral that means it's reconstructed at every boot.
So, all the primary keys are recal-regenerated.
So it uses its identity.
This is mostly added to the fact that we don't have a secure storage,
where we could persist these things.
Yeah, but it provides the PCIs.
That can be used as usual for measure boot and runtime measurements.
Yeah, and the S&P at the station report that can be requested
also includes the TPME keys, so we can then, after remote attestation,
be sure that we're talking to a valid TPM device.
Yeah, OVMF also uses volatile, if you store it right now,
it's for the same reasons, we don't know how to store it in a safe way.
Which makes it hard to configure secure boot properly.
So, because everything will be lost or you can't change the keys.
And also since we're lacking secure management mode,
we can't really protect the storage from the guest device
and enforce the if you've already had policies.
Yeah, so we have a few questions left in this whole screen.
This is, of course, we're using any equipped boot disks,
so how do we get the key to unlock the boot disk?
And also need to talk about when and how to do the remote attestation.
And the question is, maybe we can add a persistent storage
so that we can store the TPM state and the if you buy it.
But we talk about this later a little bit.
Yeah, quick overview of the TPM that we have.
So we're using the TCG reference implementation, which is written in C,
and then of course, because we unwrapped, we need an additional small C library
and we also pull an open SSL for all the crypto stuff.
Yeah, the guest can talk to that TPM via the SSM guest interface.
It's an AMD specific protocol.
And yeah, it requires enlightened drivers in in over a map and in Linux.
Yeah, I already said the thing is the firmware, but we can still use it for measured boot.
Yeah, quick overview on the roadmap, so we have our first development release plan soon.
We're working on implementing some kind of user mode tasks.
So splitting off the SSM kernel from some user tasks.
Of course, there's a lot of infrastructure and a lot of details to be implemented.
Yeah, next big thing is X2 APIC support, which is also required to make other platforms work,
except AMD.
Yeah, in the long horizon, we have the full power horizon mode that is hopefully we get there at some point.
Yeah, of course, we're working on upstreaming all the driver bits into the other projects.
And also Q and we need some patches still, they're not upstream yet.
And yeah, we hope to implement some secure persistent storage for coconut.
Okay, now we can talk a bit more about one of the main features we want to provide with SVSM, which is the state persistent.
As Oliver mentioned, our all our services now are not persistent.
So we cannot store any state and everything is rebuilt on every boot.
So we want to support state full services.
Essentially for mainly for VTPM, for state full VTPM and to use, I mean, to provide a UFI variable so that can be updated at one time by the user.
So our state, the SVSM state will contain VTPM, all the state of our services.
In order to do that, we need to persist and that kind of information somewhere.
So our idea is to provide a storage driver to SVSM, where the backend will be provided by essentially by the host in some way.
It could be a network driver or a simple file stored in a host file system.
For this reason, we need some kind of encryption on top of course.
And another requirement we are is to support multiple drivers, because SVSM, one goal of SVSM is to run on different environments.
So the main question is out to the grid to state.
And the answer is that we are ready.
So in previous presentation is to do attestation.
In this case, we will talk about the attestation, because we are really,
hardly in the boot phase.
We are in SVSM, which is a firmware, which is even before OBMF.
So we will do that attestation of course to receive the key to the grid.
To the grid, the storage that contains all the state of the services that SVSM will provide.
Our remote attestation will work.
We already talked a lot about them, but essentially SVSM will generate an assisted with the hardware,
we generate an attestation report that contains an evidence, send it to a remote server that will check that everything is fine.
So the launch measurement is the one that we expected.
So the software that is running is the software that really we want, and the hardware is a genuine hardware that provide confidentiality.
If everything is fine, the remote server will send back to SVSM the key,
and that key will be used to unlock the state.
Now we have a couple of challenges, network stack.
We don't have the network stack in SVSM, and we are not sure we want to support it and maintain it.
Yeah, exactly.
And we also want support multiple attestation protocols.
As I mentioned, we are not tied to a specific architecture, specific cloud vendor,
so we want support multiple attestation protocols.
So one of our proposal that we discussed last year at Plumber was an attestation proxy.
So essentially a simple application running into the host that will, for what all the requests coming from SVSM to the remote attestation server using an HTTP connection,
where the HTTP will be done by the host.
These architectures, several advantages like we don't need any network stack on SVSM,
and we will use feature that already works supported by VMM,
like a serial port or this connection between the SVSM and the proxy.
The drawbacks that we discussed at Plumber a lot was some cloud vendors does not provide any natural connectivity into the host.
Our application cannot reach in any way the remote server in that environment.
And also for some attestation protocol could be an issue that the TLS is ended into the host.
And so the SVSM could have some issue to authenticate the source.
So another idea that was shared by HPE, I put the link in this slide on this proposal was essentially to move that application into the guest.
So we called that attestation bridge, and it would be a essentially similar application,
but it could be for an Wi-Fi application, since you already have your Wi-Fi support and address stack.
So we can write an application and Wi-Fi application that do something similar of the proxy with a scribe.
Or it could be a minimum operating system like a very minimal Linux kernel with the application on top.
Or when in SVSM, as Oliver mentioned, we are providing support for user space,
and maybe we will provide support for standard rest in SVSM in a user space.
That which could also be an SVSM user space application.
The main advantages of this architecture is everything is self-contained into the firmware,
so everything is into the IGVM of file that Oliver mentioned,
and we don't require anything to run into the host.
So also we don't require the connectivity into the host.
We also have some drawbacks by with this approach.
And eventually the bridge will be part of the launch management,
so if you have some kind of CVS,
since the bridge could be a big part of the firmware,
you need to update your IGVM and your launch management.
The bridge also requires some kind of setup,
so the VMM needs to, I mean, we need to define some kind of configuration
to tell to the bridge how to configure the network.
And the bridge phase could be a bit more complex,
because SVSM needs to build this kind of bridge that could be like a temporary VM
or something like that, then draw everything away.
I mean, use it to get the secret to unlock the storage,
then draw away everything and start the real OVM map and guest.
And so talking about the state,
we have some potential attacks we want to prevent,
which are essentially rollback and clone attacks,
with rollback and host can,
and many users can provide to SVSM state,
which is included with the right key,
but could be an old state.
This kind of attacks can, for example,
hand-down some update on the second boot keys we stored
into the UFI viable store.
And the clone attacks is the host can spawn multiple VMs
with the same SVSM state,
so we're using the multiple VMs,
we will use the same TPN,
which can back the uniqueity of the TPN.
And in order to protect this attacks,
we have something in mind like for the rollback,
use a boot counter,
and for clone,
we can allow successful attacks station only
for a single instance for the VTPM identity,
only one time for each request coming from the user.
Anyway, if you are interested about those,
we are discussing in the TCG virtualization platform working group,
possible changes to the TPN specification,
and also support attestation protocols.
We need to put some links here,
so if you are interested, please join.
Now, just to recap everything,
so our boot phase will work.
Essentially, the first step,
the hypervisor will load into the confidential VM memory,
the SVSM and the VM map from the IGVM file,
and SVSM will boot.
During the boot, we need to talk with the SVS,
so we need to talk with the remote server,
using the proxy of the breach,
and generate the attestation reaper,
send it to the server,
and receive back the key to unlock the storage.
At this point,
the SVSM can utilise the TPN,
the virtual TPN,
and UFI viable service,
and contain the boot's launching of VMF.
How VMF can use second boot,
and measure boot,
thanks to the TPN,
and can then launch the operating system,
which will be able to use the TPN
to, essentially,
a state full TPN,
so it can be used to do the looks,
looks key,
or unsealing,
and then automatically mount the root file system.
We have a demo, of course,
we don't have time,
so we put a link,
it's a complete demo,
a proof of concept, of course,
with everything we saw,
and also we maintain a copper repo,
so if you want to try,
essentially,
some of the changes that we need in a state
in Linux, Quimo,
and the ADK2 are not yet upstream,
so if you want to try,
we have a copper repo with all of those packages,
plus SVS.
Yeah, that's time for question.
Thank you.
So, she's got a question.
First of all, it's an observation
that we should have been on this,
and yesterday, in the presentation, I show.
So, you can,
instead of,
we either proxy,
or pre-shoot,
to multiple,
to terminate the TLS,
you start inside the TPN,
and use the proxy as just the transport,
Yeah.
Because,
if you are ready to pulling in,
it's open as a set, right?
Right.
If you have the bio-ups,
actually,
you have the bio-in bio-ride bio-connect,
yeah.
And then you have the guy,
which is a good point.
I will repeat what,
I mean, it's an observation,
as a Justin for us.
Essentially,
he's suggesting to,
instead of using the proxy,
or the bridge,
we can do something like a mix,
using the proxy just to,
just really as a proxy,
and the TLS connection into the bridge.
So, in this case,
the proxy will be used for the real,
TCP connection,
and TLS will be handed into SVSM.
This will solve the TLS issue,
but we still have this issue of,
some common vendors that doesn't
have connection into the host hypervisor.
So, maybe we need to support both,
but yeah, thank you.
So, you can,
you can,
you mean,
SVSM will generate it.
So,
you can,
as a sense,
you can,
yeah.
So,
actually,
the current implementation,
the endorsement key,
sorry,
the question is,
thank you,
the question is,
as SVSM,
the TPM,
into SVSM and endorsement key,
yes,
that endorsement key,
currently,
is generated randomly,
a total boot.
The idea is to,
when we support the storage,
is to provide also an offline tool,
that you can use to install,
which key,
do you want?
I'd like to file on to what Thomas said,
because,
the SIM card industry has been using,
this model that he described,
with DLS in the sort of trusted execution environment,
for more than 25 years.
So, like,
if they managed to get it done,
I think it's possible,
in a virtual machine,
yeah,
like from a performance,
but in the source and on a problem,
because they are also,
nobody directly,
since,
like,
the message is directly to the SIM card,
but instead,
the option outside,
that needs to initiate the connection first,
because otherwise,
the server that infrastructure is,
and indeed,
to contact.
Okay.
There is some machinery,
but,
it's manageable.
Yeah,
so there's presidents.
Okay.
Yeah?
Just back up on the endorsement key,
question,
how do you,
how do you trust the virtual TPM?
It sounds like what we need,
is another bond,
chat on the artist's statement,
the confidential TAM,
rather than the TPM,
just the TPM.
So, the hardware TPM,
there's a certificate over here.
Okay.
It means I know it's by a hardware,
by TPM.
This is an extremely device.
This is sort of constructed by the cloth,
and the confidential TPM.
There's no direct trust path,
though,
being able to say,
this is the TPM that is definitely
trustworthy.
There's an extra step,
that wasn't entirely carried in the diagram.
Yeah.
We didn't,
essentially we didn't,
the question is,
the real TPM has some kind of,
some kind,
as a certificate that prove
that the endorsement key is essentially
identical identity of the,
of who generated the endorsement key.
Do we have something there?
The answer is currently no,
but when we will provide the state full TPM,
we can provide the tool,
and you can essentially generate
whatever you want,
and you stole also the endorsement key.
So we'll be up to the user,
to the user,
to configure the SBSM,
to do that steps.
The problem with this is that in a quiet environment,
the quiet vendor is the opposite rate.
So you don't have a natural person.
We can do all of those checks,
I'm providing signature,
that is just a third point.
That's the piece that is missing,
and I would love to see a solution for it.
Yeah.
We are providing the building blocks,
and we are not working on currently,
on that things.
But the building blocks will be there.
So essentially,
if there will be a certification authority,
that the user want to choose,
they will be able to store whatever they want
into the virtual TPM,
and then check the identity.
Okay.
Sorry.
One more question.
Who are like real world and constructive?
How do you suppose who will specify which
the decisions are worth deducting?
And the expected say publicly of it?
The question is,
when we use,
when we talk with the remote attestations somewhere,
we have multiple guests, right?
Right.
It gets you to want to talk to some sort,
or how do you specify it,
like where is it stored, right?
It would be,
it would be stored into the IGVM,
in some way,
or provided in some other way,
by the IPR-wise or TOSVSM.
So when you start your VM,
you will configure SVSM with,
I mean,
with the destination server you want to reach.
For example,
in the case of the proxy,
you will launch the proxy,
specifying where the remote server is,
need to be reached.
Like you have one proxy for the,
for all the guests on the host.
They will all talk to the same destation server.
You can spawn multiple proxy,
if you want.
So our idea for now is to have one proxy for each VM.
Okay.
Thank you.