All right, it's about time.
Let's get started.
Where come to my talk about securing the Linux Boot
process with coconut SESM?
My name is Jogrøde.
I work for the AMD server department.
Actually, the top title is not 100% accurate,
because it's not only about the Linux Boot.
It's also about the Linux runtime
and what coconut can do to actually make
that most secure in a confidential VM.
First of all, what is coconut SESM?
It's a secure VM service module
that is what SESM stands for.
In open source project, which was published in March 2023,
it provides services for confidential VMs.
It is part of the TCV.
It is actually a part of the software part.
It is trusted by the CVM.
It was written in Rust
and security is the number one priority.
This means that the project creates security for performance,
or we take performance heads to actually increase the security of the project.
So, we always make the trade-off towards security.
First of all, some introduction,
so that everyone is in the same page.
Most of you probably know this already, but let's get a bit into this.
With confidential virtual machines,
we get nice things like memory encryption and things,
and everything is supposed to be secure.
But there is a caveat that is that it actually introduces a trust boundary.
That is not there without a confidential VM.
That is the trust boundary between the hypervisor and the guest.
Actually, when you run your confidential VM,
your guest is running inside of that VM,
cannot trust the hypervisor or anything the hypervisor does.
And the hypervisor actually does a lot of things.
First of all, it provides devices like clocks,
storage devices, network devices,
and it also provides a TPM,
which you can usually use to unlock your disk.
There have been a few stations yesterday in the virtualization program about that.
All of this is usually provided by the hypervisor,
and in the confidential VM, this is no longer actually trusted.
So what can we do about that?
Before we get into the solution,
I want to introduce a bit more of the,
I want to refresh your memories on some of the features
that confidential hardware extensions actually provide,
and how they provide these guarantees.
Of course, memory is encrypted,
but it's not the whole story.
Convenientity VMs actually also provide memory integrity,
and they do that we are introducing states to actual pages.
So pages have on a high level three states.
There are the hypervisor page, which means it's a host page.
There are the unvalidated guest page,
and there's a very dated guest page.
The hypervisor can change pages from hypervisor to unvalidated guest,
and the guest can only change from unvalidated to validated.
That's how the hardware makes sure that the hypervisor cannot actually replay
all contents of encrypted memory,
or we map your encrypted pages within the guest
to actually provide memory integrity.
The thing here is that the guest actually needs to make sure that
each page is only validated once, otherwise,
when we integrity can no longer be guaranteed,
and that's important to remember that for a latest slide.
Convenientity VMs also provide registered state encryption,
so an AMD SIGSNP, this is done via VMA pages,
which contain all the VCPU state registers,
FPU state, controller registers, certain MSRs and things.
And all of these are encrypted on VMx,
and decrypted on VMrun.
The outside is hypervisor can no longer handle intercept,
so there needs to be solution for this,
and the solution to hardware has,
is basically turning exceptions into,
no, turning intercept into exceptions inside the guest,
so the guest actually,
in fact, hinders its own virtualization intercept.
To do that, of course, need to talk to the hypervisor,
and for that there is a parameter virtualized protocol,
the GHDV protocol,
we can actually get the information from the host on how to,
on how to fulfill the things that cross the intercept.
MSR reads in writes, for example,
if the guest access is in X2, if the MSR,
of course needs to talk to the host,
but it will first end up in the VC,
exception handler in the guest,
and then it will call the host,
and GHDV protocol to actually make the MSR read all right.
And the last feature I want to talk about,
which is pretty substantial.
For co-connect, it is VM of the imprivileged letters.
This is actually a hardware feature
that allows memory partitioning within the confidential VM
on an VMV SDK SNP guest.
So it, the main feature is actually that you can,
protect, you can hide memory of your guest physical
interface from higher VMPS.
So you can run software in the,
in the highest probability stable, which is VMPS zero.
And this can set a memory protection,
so actually prevent anything running in VMP 11 to 3
from access its own memory,
even with the same guest.
Well, this is a pretty, pretty important feature.
For co-connect, it is VM,
because it actually means we can run higher probability
software at VMPS zero that keeps secrets
or basically shields a bit.
The guest to S from the hypervisor.
But of course, there needs to be a mechanism where the VMPS
can talk to each other.
And that mechanism is the SVS protocol.
There is another parallel to S protocol,
which is completely inside the guest.
So everything is encrypted.
The hypervisor cannot see what they are talking about.
So this is actually a functionality,
where the guest to S running at VMPS zero.
So this is the current default in coconut.
To the SVS and running at VMPS zero.
And this allows the, the SVS to provide certain services.
I said it's a service module, so currently it provides services.
Some of the, some of the services are the co-protocol,
which is, which I'm not covering more here today.
And the, not the important one is the TPM protocol.
There's also an adaptation protocol to actually fetch
VMPS zero, adaptation report, and get service
attestations and things.
The communication of the protocol works via via the VMSA.
So everything is basic.
VMPS two puts state into registers,
called VMPS zero.
VMPS zero can read it from the VMSA and execute on it.
And with that, we can actually extend our picture
from the confidential VM by having coconut running in VMPS zero
and moving the guest to SVS to VMPS two.
And as I said, the, the memory of coconut SVS
is actually isolated from from the guest to SVS.
So the guest to SVS cannot access any SVS memory directly.
Which is the create benefit for emulating certain pieces of hardware
that cannot be emulated securely in the host like TPMS.
TPMS have state that basically forms a root of trust.
And so there's, there's no way to actually emulate
some security in a hypervisor for confidential VM.
And so with coconut SVS, the TPM emulation can actually be moved to the SVSM.
And because the SVS, actually runs within the TCP,
this makes the TPM at least trusted again.
And with a trusted TPM, we get all the good features like.
A root of trust for the for the for the food process.
So you can bend the, when the TPM has, has persistence.
You can actually have, have, have is that EK to the,
to the, a predefined EK, which you can trust to your,
in your emulated TPM, you can make the TPM itself trusted
by the hardware adaptation report.
So the actual root of trust is the hardware adaptation report,
but that proves the security of the TPM,
which is then the root of trust for the filter.
Steps in the, in the boot process,
it can store secret and even provide,
provide identity, it can be useful,
unlocking your, your disks,
all of that with the TPM running in coconut SVSM.
So by the TPM is not the only service that coconut can provide,
today it does not provide the service is talking now about,
but that's kind of record.
Another service, it could actually provide,
is helping out with memory integrity.
I said before that memory of the confidential,
we need to be validated by the guest,
and the important part is it needs only to be validated once,
otherwise the security issue.
So double validation must be avoided,
and the way this is usually implemented,
is that the guest has a bit map where it basically keeps
a picture of which page is validated,
and which is not validated,
and then if it detects a double validation then,
yeah, then there must be actually,
it's a security issue or software bug.
So doing this in the operating system is actually a bit problematic,
because this is a bit more of that needs to be kept,
doing the whole VM lifetime,
and that we have lifetime even starts before the guest is boot.
So this lifetime starts actually when the firmware starts,
when the firmware starts running.
So from this time on the information,
what page is validated,
and which is not validated,
it needs to be kept up to date,
until the full guest is booted,
and even beyond that even if the guest KXX or something,
this information must be kept in place and passed forward.
And for the guest to add,
this is a bit of a challenge of implementing all of this.
So as nervous as he is,
he is a quick provider is actually moving that integrity,
checks to a coconut as he is a coconut as he is in this called,
any way for memorabilitation operations,
because that's something that can only be done in VMPL zero.
It's required, the PPD data instruction,
which does not run on non-zero VMPL's.
So why not keep all this information in coconut,
and that coconut here, the guest to us,
when something goes wrong.
So that's one idea,
another idea that is actually actively being worked on,
is the UEFI variable store,
that's a feature that is needed for secure boot.
When you don't trust your host,
your current store, your UEFI variable,
on the host, or something like that,
the host can see it.
And you actually need to hide those variables,
also from the guest to us, for secure boot,
to actually be secure.
So the SVSM is a good place to actually store these variables,
because it protects it both from the host and from the guest to us.
And this will actually get us secure boot in a SVS in PBM.
And the more advanced features that coconut could provide it
could actually be some kind of proxy for network and storage,
provisioning to the guest to us.
Because as I said,
everything the hypervisor usually does is untrusted,
which means that the devices it invulates is untrusted.
Which in turn means that the guest to us is required to harden
its device drivers,
to not be attackable by malicious host device models,
host implementations of device models.
So this is actually quite difficult and hard to do,
and always the best effort to think for the guest to us
to harden its device drivers.
So this is also something coconut SVS can help with.
But for that, we need to talk about two additional features
that SVS and P provides,
which the first one is reflective.
We see and the other one is alternate injection.
Because the features we actually talked about,
that's not actually allowed for the device
in relation as the SVSM has no way to actually
hinder any memory map IO accesses or inject interrupts
into the guest.
But this is different with reflective.
We see an alternate injection with these features,
actually,
when enabling reflect we see,
that we see exception that they talked about,
that are handled by the guest to us itself,
can now be moved out of the guest to us into the SVSM.
The SVSM hinders the SVS exceptions,
and since there are the SVS exceptions also
for memory map IO accesses,
SVSM will also see them and can actually emulate
in memory of the guest.
And the other one is alternate injection,
which gives the SVSM the ability to actually inject
our Qs itself into VMPL2.
There are actually fields in the VMSA for that
to inject our Qs into other VMPLs.
And with these two features,
we actually have the first set we need for device
proxy or device emulation.
So we get memory emulation.
We can actually emulate apex,
because apex or if I exist via memory as well,
or by MSRs,
which also cause VCs,
which would then auto be handled in VMPL0.
And we can inject our Qs.
So this actually gives us the full feature set
from the hardware for doing device emulation
in a lower VMPL.
And with that,
we already talked about the TPM,
that's already in coconut SVSM.
With those features,
we could actually build proxies.
In coconut SVSM for the device model,
that the hardware was provided.
There are different ideas here,
so one is to keep it a bit simple,
of just being basically proxy for the host device
in the SVSM,
the outer SVSM,
basically having a full device emulation,
SVSM,
and accessing some sort of host device.
So the host provides,
for example, for storage.
The host only provides a multi-ode device,
but for the guest to ask SVSM,
that's in VMEDI-wise, for example,
those things are possible,
for the device emulation.
Or the SVSM could just check the input
from the hypervisor before running it to the guest to S.
And this is also true for the network,
of course, for basically for all devices,
the SVSM,
for all devices that the SVS,
the hypervisor emulates,
there can be a proxy within coconut SVSM.
And this actually makes it less important
that the guest to S. Harbenset device drivers,
because the malicious input is shielded away
from by coconut SVSM,
which is much smaller,
and which can more easily handle it,
and be transferred within the TCP,
though actually device models,
running within coconut,
can be trusted by the guest to S.
So there's less need to actually,
have the device drivers,
which makes not only the boot-musical,
but also the runtime of the VM,
of the confidential VM.
And with that,
I'm already at the end of my session.
Thanks for listening,
and I think we have some time for questions.
Thank you.
So, the question is,
how we can ensure that the EK of the TCP and the trusted,
how we can,
the loss of the key to the power of the press?
So there are,
so the question is,
how we can ensure that the EK of the TCP and the trusted,
there are actually two ways.
So currently,
the TPM in coconut has not,
does not have persistent state,
which means that the EK is reach generated at every boot,
which means,
and the trust is actually established
by a hardware adaptation report.
So there is,
the,
the hash of the EK is actually put into a VMPSE
or a dissertation report,
and then you can verify that a dissertation report
and see that the key is trusted.
And that is,
that actually was generated by the trusted version
of the SVSM because the SVSM is part of the root measurement.
So,
and for the persistent,
apart,
the EK is actually provided by the guest owner
on,
together with the guest image.
And,
then the guest owner has to make sure that it's actually,
that it's the key,
it's,
that,
that this is the key,
it actually created and deployed.
Then the pilot came to provide
by the guest owner.
Yes,
the private key is provided by the guest owner.
Yeah, so actually,
the, the, the whole TPM state
can be,
when the,
when the STPM persistence,
and for the assume the case,
we can provide the 4TPM state,
including the,
including a pre-creative EK,
which then has,
which then is trusted by,
the guest owner,
because it actually created it,
or however,
the guest owner wants to establish trust in its EK.
Yeah,
Thanks for the talk.
You share quite some low level details about
this architecture.
Then you comment on whether
coconut will also support other
the potential PMs like IntelTD,
so RCCA,
and why not with the challenging order.
So the question was about supporting
IntelTDX,
and RCCA.
We actually have code and coconut
to support IntelTDX.
So I talked about the VMPL feature,
and there's something similar
on the TDX architecture,
and also in the CCA architecture,
and TDX,
it's called Partitions,
and in CCA,
it's called Plains.
It basically works pretty similar
on board architectures.
There's,
there are some key difference to,
differences to how AMD implement this.
Though the features I talked about,
like reflect we see,
that's actually implicit in,
in TDX partitioning and in CCA.
And,
and, and, and, and the levels
which just can actually happen with
in the guest context.
So,
on AMD to switch VMPL to go back to the
Hypervisor,
called Hypervisor to switch the VMPL to something else.
On, on Intel,
and, and arm,
it's, it's happening with,
with in the guest.
Um,
which actually makes,
the X, the pure SVSM mode,
where the SVSM provides a,
and SVSM protocol to the guest.
Um,
pretty much useless for these architectures.
What you want for these architectures is a,
it's kind of a full,
a full emulation,
like,
um,
hand,
basically handling the,
on, on TDX,
which would be the VE exceptions on,
on, in, in, in, in the SVSM basically,
um,
yeah, it's basically the,
the power was a model,
where the,
the SVSM turns into a full,
not, not a full,
but a small hypervisor layer within
the guest.
So.
Next up.
Thanks.
Yeah.
In the other questions,
yeah.
So,
when you use this in the
question,
and then you pass through devices,
um,
how would you expose this to,
the guest,
does this to hurt anyone?
How?
So,
you,
play,
thank me.
,
you,
sorry.
Yeah.
You,
you,
r to the whole,
it's a,
This,
We can also do better over course, but
Can I actually do must must device this?
Thank you