Thank you everyone.
Hello, so today we are going to talk about confidential virtual machines, we will
demystify them for you.
We will try to understand the system stack that supports confidential virtual machines.
And for the first part of the presentation, we will learn about what enlightenment means.
And for the second part of the presentation, we are going to speak about how we can achieve
that enlightenment.
So, I am Arjuna.
This is Ankitav.
We are both from Asharlirak's team at Microsoft.
Asharlirak's is a first-party distribution.
And lately we have been working on enabling CVMs on Asharl's confidential virtual machines.
So, let's begin.
What they expect by the end of this talk, you should be able to understand what confidential
virtual machines are.
What are some cloud provider trends.
And so in this talk, we will be focused on confidential virtual machines provided by
top providers.
Also, these concepts that we will learn about UK, IC, output, measure, boot, whatever.
These are as applicable to bar metals also.
But we will be focused on cloud providers and we will learn about certain gaps.
And you will learn about what you need to configure to enable your operating system
image for confidential virtual machines.
Okay.
So, let's start from basics.
Confidential virtual machines are an implementation of confidential compute, protects our data
in use.
And the T level, the trusted execution environment, boundary exists on VM level.
So, that means your data in users predicted from the high-privileged layers such as your host
OS or hypervisor or emulator devices.
It offers the most flexible approach.
For example, compare to the application level on clear based implementations of T, you can just
if you have something on your cloud instance or in your VM, you can just easily lift
and shift that application inside a confidential virtual machine as of today.
Provides remote administration facilities, you can gain the stress that you are running inside
a confidential virtual machine environment.
You can derive that route of press from the hardware.
It is obviously backed by CPU vendors.
The hardware extensions make it possible to encrypt memory.
AMD 7SMP, Intel TDX, there are many others that support this.
We are going to be focused on AMD 7SMP and TDX for this talk.
Cloud providers are no stranger to this technology.
They have been adopting it and they have been enabling SKUs on their inferred to support this
into N2D and C3 are recent announcements.
And Microsoft for example, have also supported our confidential GPU with confidential virtual
machines.
So why are we talking about this?
Confidential machines allowed cloud providers to guarantee this that you now have your
customer data.
They will have more access to your sensitive workload.
It is protected from your higher privileged layers.
So now as a user, for example, you have sensitive application running on your
machine.
You can reduce costs.
Maybe you can move them onto the cloud.
So it increases those use cases and they just are taking.
They are enabling these for you.
Okay.
What is memory encryption in CVM and chain then?
How does the system stack differ?
So you do need a special stack for management communication and ensuring the security
benefits of confidential virtual machine.
Compared to a normal VM and compared to a normal VM.
For example, you are host and VMM.
Once your VMM has allocated the memory for the guest, it has more access to that environment
that gets itself.
The control is then with the cost gas firmware, gas firmware takes the initial measurements
and it will store it.
And then guest kernel is CVM aware.
What that means is that you need to enable some configurations in the guest kernel itself.
And that is required because guest kernel is responsible for example for declaring what
pages are private to it and then there are some shared pages also between host and guest
that are taken care of by guest kernel.
The VMM VMM communication transferring from guest to host or host to guest mode happens through
VM exit events in a normal VM.
Whereas in confidential virtual machines, it happens through VMG exit, for example, in AMD and
TV call, it happens in TVX.
And this is a specialized communication protocol that I developed for VM and VMM communication.
For IO operations and MMI, the direct access is there in normal VM and happens through VM
exit events only.
But in confidential VM as we discussed, it happens through explicit VMM calls.
In normal VM, IO will raise exceptions such as VC and VE.
And direct memory access, open device access and normal VM, but in confidential VMs,
it happens through a dedicated bounce buffer.
So that also sometimes adds overhead and confidential GPUs,
an example where you can have a dedicated device to T where the device itself is
attested.
And special communication protocol exists between the device and the confidential virtual
machine itself.
So moving on is memory encryption enough to guarantee confidentiality and cloud VMs.
Let's learn about that.
So VMs and guest OS, where is the problem?
confidentiality guarantee does not apply to guest OS.
What that means is that once your inside, once you have your memory allocated to the guest,
what is running inside the guest itself, let's see your system executables,
they can see the workload that is running within it.
They have access to it.
And secondly, as I said, there are pages which are declared which are shared between guest
and host and that is taken care of by guest kernel itself.
So you have to be careful about your guest OS itself.
And that is why protecting guest OS is important.
And how do you do that?
How do you do that?
For example, when the launch VM, they will load this image from somewhere.
It is lying somewhere.
They will bring up your guest and you need to protect this image.
So you have to ensure your data at rest and data in use both are protected.
Data in use is protected with memory encryption.
And for description, we'll protect your data at rest as well.
And you have to achieve this without relying on the host.
So you cannot give your decryption keys to the host.
It will allow us to encrypt the OS image.
And you have to also support at end it and at end it boot.
You cannot type in your password because host can slip on it.
You're trusting your cloud provider with that password.
You cannot do that.
The solutions to that, you can use VTPM.
VTPM's, VTPM's are higher chips.
That support, they can store your keys.
And you can use them to also perform side-of-the-date options,
like decryption, encryption, etc.
But you need to place some trust in your cloud provider.
Because these are usually implementations from cloud itself.
Alternative work, remote administration.
In your boot path somewhere, you attach to the environment itself.
And then bring your OS image and bring it up.
You don't trust the cloud at least.
How would a consumer know what it is and how it is?
So your evidence, it is derived from root of trust.
PSP, which is that one-secret processor, encoding on-kift, T-DX and AMD.
Where how would basic audio modules you can generate your attestation evidence from there.
They are signed by keys from Haru vendors.
Then you can fetch your certificates.
So the vendors would give you certificates.
You can use those certificates to verify the authenticity of the support and case your test in the environment itself.
Talk to others.
Usually you have their implementation of verifier, such as MA, Google administration,
Agent or Intel just authority.
You can build your own verifier.
If you don't want to place any trust in those as well.
Okay.
I'll skip this diagram.
But it shows how the attestation happens.
Basic and AMD service empty was intended to T-DX.
I'll transfer to Ankata for file data.
Here it's enough.
So you should have time, but okay.
So what is the guest kernel?
Out of the guest OS need to take care of at this point.
It needs to take care of the kernel.
We need to have some patches applied already for service empty and T-DX.
We need to enable certain kernel configurations.
Then for protecting the data at rest.
We need to have full description.
Secure boot is needed so that at each step of the boot chain,
we know that only trusted goods are executing.
And then since we are encrypting the disk, we also need to give the password only
when the system isn't a good known state.
So these are the kernel configurations that you must enable.
The first two ones are the mandatory which are necessary.
The second kernel configurations basically are optional.
And they are mainly if you want to attest using the hardware root of trust.
So how do you boot the Linux in a secure fashion?
This is a traditional Linux boot chain.
We have the form where which loads the boot loader.
Then they'll kernel followed by any parameters.
And then we as the user for the password and then you'll be Crypto OS volume.
However, with this secure boot, we have a signature check at each step.
And this applies until the Linux kernel where, you know, the boot chain is secured until
your Linux kernel.
So this is how the secure boot works.
But is this still enough for a confidential VM?
Actually, no.
Because what if some arbitrary in a parameters comes into picture at this point?
How do you still protect your boot chain?
So this has been simplified with the concept of UKI or unified kernel image.
Where we combine all these three components, the kernel in a parameters and the kernel
come online into a single UEFI binary, which can be easily integrated with the UEFI secure boot.
And it is signed by the certificate of the distribution vendor.
So this is how the CVM secure boot flow would look like with the help of UKI.
You don't need to sign those three components separately.
Or you don't need to take care of them separately.
You can use the UKI for that matter.
Why you have already spoken about these three points?
However, there is a slight flexibility tradeoff that comes with the security of the UKI.
We have a static in a parameters.
So you cannot do any runtime module customization with your kernel.
Secondly, the kernel command line is static.
So you need to have a mechanism to discover your root volume.
You cannot just go and put in the GUID of your root volume and it's going to be gripped.
And then there is no traditional UI like the bootloader UI that we have usually.
So then, as we already spoke about the system, the boot chain is secured using secure boot.
But we still need to know that, are we revealing the password for our root volume to a good system state?
It is actually the genuine CVM that we want to reveal it to.
So that is where the measured boot comes into picture.
It is a standard way for checking the authenticity of our boot chain.
And this is done using PPMs and something called platform configuration registers or PCR.
What happens is at each step of the boot chain.
We basically take the hash of each component of the boot chain.
For example, the shame, the system reboot, etc.
And then all of these hashes are recorded in your TPMs.
When the system boots, these hashes are recorded while the booting process.
And then, finally, the PCR prediction is checked with the action.
You know, PCR measurements that we already had in the TPM.
If both of them match only then, we, you know, reveal the key to the root volume.
So that we can be gripped at OS root volume from there on.
So we have been talking so much about this encryption.
Let's see how the display out differs.
So now, standard VM, you just have a boot partition, a root partition.
Optionally, you have encryption in the root partition.
Where in the boot partition, we have all the graph files or the boot loader files.
The kernel command line in the traffic, etc.
However, all of that has been squeezed down into the UK with our CVM.
Talking about the root partition, we use usually standard encryption and we store the password.
Either, you know, in a file or we from the user to give it to us.
In this case, we don't need to do that.
We use LUKS for encryption and then there are certain key slots,
which are sealed by the TPM as we already spoke about.
And they can be used for the decryption.
Of course, the root volume is encrypted with the user data.
So this is a quick flow of how the free description encryption and decryption is working.
We have an LUKS container on the root volume.
Which generates a master key.
We create a TPM policy.
See the key with the TPM.
And then, you know, we store that key in the metadata as I already spoke about.
And we encrypt the root volume.
This is how the root decryption works.
And we have already spoken about this one.
So that brings us to the end of the store.
That time is also up.
Just one minute I'll take for this one.
So this is what, you know, other key takeaways.
And we hope you were in lighten by the end of this talk.
Thank you.
Just a quick.
Thank you.
Thank you. Thank you so much.
Do you have other references?
And I would just like to mention we have a talk coming up to water by vitally in the conference.
In the virtualization bedroom.
On a similar topic, with some updates.
So please go and check it out.
Thank you.