Hello everyone, my name is Vitali, today was me, I have, oh, it's actually not only for
the good fortune.
I have Aminole, we are both from Red Hat, we are from the platform development, so we are
taking part in development like Fedora and Rao, I have had, and today here we are going
to talk about confidential computing guests and in particular how you can actually make a
confidential storage for it.
So, a consortia computing has been a while, you know, hardware vendors came up with
a lot.
So, I don't think I need to explain them a lot.
You can nowadays quickly get a confidential V, which is going to be called confidential from
say major cloud providers, all three big, like Azure, Google, AWS, they all give you
this option, so it's basically click-click and you will get something which is called
the confidential VM, but then if you look at what these technologies really give you,
they give you like memory encryption, memory consistency, CPU register protection, but
there is nothing there about the storage, right, from where your operating system boot,
and you know what's there, it's all left to the operating system you run there, right,
so left there, whatever.
Thank you.
.
And then use in a way that the host cannot actually read the key.
Whatever you are doing with the storage, it needs to be a testable, I call it.
So, you are able to prove to somebody that you actually done that, right, so if you use
like Verity on your root disk, you should be able to prove to somebody, say, hey, here is my
like this year's signed by my TPM, I can prove that I really used it this way.
And also, like, last but not least, the rollback protection, because even though if you are using
something like encrypted on the disk, an able host may try to roll back some parts of this storage for you,
like, a partition, right, think about you install an update, fix some CV, and it will
host just rewards it back, right, so that's also like a risk.
Okay, so now, I'm going to take from here and call us what we are working on,
mostly like in system disk space, but not only.
But Verity, DM Verities, okay, some already.
I just quick summary is integrity checking for block devices, basically it's enforced by the kernel,
and it's basically making sure that the target partition that you want to vary to protect has not been
modified by anything, and practically this means there is another new partition created that
creates a tree of hashes where the leaves in this tree are the actually the hash of each block or
sector inside the target partition, and then there is each parent is the hash of the hash
and so until you get to a root hash.
And there is a rich support in system D for this, for DM Verity, so there is system D
a part is capable of creating automatically dissolved partition.
Verity is a top generator also detects and does this check at boot, and there is
common line support like a root hash and use rash as we'll see later.
And yeah, so the big downside of Verity protection is by design, of course if you
want to maintain that the disk is not the partition not modified, it has to stay
redolly.
So it's you cannot change the partition to anything else once it's mounted as a Verity.
So you can achieve root with root hash, you target the root partition, and of course
is redolly, and there is a possibility at the moment with system D volatile to add
a femoral overlay.
Otherwise there is use rash, which targets only the slashes partition as a Verity.
And this is used in the Hermetic use approach, which is the idea, as we'll see later
that basically the use, you boot with the only the use partition, which is the
M Verity project.
So yeah, from the, so we looked quickly a Verity, and now we look at the
encryption on the other side encryption.
A lot is great because it provides encryption and the read right.
So now we can actually modify the partition because only Verity is pretty useless for a
generic virtual machine use case.
But the issue is if you want to have an encrypted partition like Vitalis at the beginning
each VM instance or volume needs to be automatically encrypted.
And the question is by what, like, do you need to trust some trust and infrastructure
that encrypts it for you or like the goal of also our work is to enable self encryption.
So at the first boot, the VM itself, we start from something and it creates the partition
and encrypt the partition.
Most of the report, of course, supports also lacks, there is the possibility to see
the keys to the VTPM.
And there is integrity protection coming in the version 26, but even though full rollback attacks
are always possible.
And currently there is also a new feature that to ensure that once you create an encrypted volume
it does not get replaced before it's been actually mounted and used.
Maybe you want to add something, huh?
Yeah, I can elaborate a little bit on this feature.
So for the Verity protection, oh, no.
For integrity protection of a lacks device, it's a built feature of like crypt setup.
And it's there for quite a while, I think, like five years or so.
And still stays experimental.
One of the reasons it's experimental because there was no support for it in the user space.
I don't know, many users enable it.
We want to change that and the first thing we've introduced an option to SystemD
Repart to exige and rate Verity integrity information for the created partition.
With fixating the lacks key, it's quite interesting because I think about the use case, right?
You boot and you want to create a lacks partition, right?
So you're like, okay, here is an empty partition.
I'm going to get run like crypt setup against it.
I'm going to seal the key to the TPM with my current values.
And then I'm going to mount it.
The problem is that if you have like an evil host, it can actually replace the whole lacks volume
right after you create it.
And also seal the key to the TPM because to seal the key to the TPM, you only need to know the public key of the TPM.
You don't need anything else.
So how do you do it, right?
So this feature looks small, but it allows you to basically capture the snapshot of the lacks key when you're creating it,
but it's still a memory.
And the memory in cocaugust is still protected.
And then you can be sure that you're actually mounting the volume which you've just created and not something else.
Yeah, so to continue the goal is to put these two concepts together.
So where it is together with encryption to get the full read bright experience.
So the idea, there are three different ways to do it.
The first is very basic.
So you copy everything from the very protected volume to the encrypted one.
So when you boot, it's too trivial.
And also it takes probably time if we talk about the route is copying everything.
Then there is the using on overlay.
So basically the idea is that you put, you still mount the very partition.
You put an overlay that, so that every brights on the variety partition gets redirect to the encrypted partition.
And then there is also this interesting idea of the mclone, which is basically on the background,
the copies from the very partition to the encrypted volume.
And while it does, you can still use the disk normally.
So go ahead.
Yeah, so as I said before, there are two way, like at the moment, it's support.
Verity targets the route and the user in system D.
So with the route hash, basically you give the hash, which map should map to the route of the hash tree in the very partition.
Need automatically system D is able to automatically found the route partition and also the very partition.
So it verifies that the hash should match and it's mounted.
And but currently this cannot be combined with the persistent overlay.
There is only the volatile option.
It should also make sense because in the general use case, if you have, for example, IO, IO workloads with overlay is not ideal.
On the other side, there is use ratio which only handles the use partition.
And here is where we are working on to handle, like, we try to follow the romantic approach.
So you boot with all these, as partition, which should have all the necessary files.
It's DM verity.
Then the route is created by system D report and encrypted at first boot, which is pretty fast because it's an empty partition.
And this also handle already by system D report.
And then you mount as less use as redolly because it's very, and then you add overlay on top of it, so that is less use results are right above.
And the rights ends up in the encrypted partition.
And this way, the overlay only covers the less use, which should be better ideally.
Yeah, and then Vitali, we'll talk about the include.
Thank you. So, like a simple approach, how we can switch from something which is where to protect it into something which is red right and encrypted is to use like a file system overlay, which I'm going to just talk about.
But for, like, Leonard is not in the room, I can say, we have users which want to have more complex storage configurations and they use something like LVM, right.
So, that's, and the thing is, imagine you have an image, like an operating system image on a cloud, which has like multiple volumes.
You will need to very to protect each of these volumes, right, and then when you create writeable overlays, you kind of put them all on the same disk because that's not why these people want to have separate partitions.
They are probably following some guidelines or some certifications tenders.
And these are coming from 90s, you know, where it's written that you know like their bar partition needs to be separate, your home partition needs to be separate.
It's just like written there, and this user's, we want this because it's written here, right.
So, you cannot put all this overlays on the single partition. You will need to create as many overlays as you have partitions.
And then the question is, how do you manage such storage? If you want to give more space or something, it becomes like a nightmare.
So, we are also looking at the thing called DM clone, and I don't know how many of you like have seen it.
It's probably not well known, but it's very similar to DM snapshot in the kernel, where you can take some like read only partition and say, hey, I want to have like a writeable overlay on top of that.
The only difference is not only, but the main difference is that DM clone converges, you know, so it copies the source partition in the background.
So, you basically can mount this device and start using it right away in early boot, and you don't need to wait until all the data is copied.
But at the end of the process, you have a full copy, and it's also like read right for you, right. You can get rid of the initial one, which sounds cool.
But currently, there is no support whatsoever in the user space for it. So, you kind of have like it is C and a clon tab, right, and describe, I want to create these clones on the early boot.
You can only do it with like DM set up something manually. So, we are trying to solve this, there is a proposal in like system D again, where this has been discussed.
So, next, if you remember, I told you that whatever we are doing with the storage needs to be accessible.
So, we need to be able to prove to somebody like in the mode of the station scenario that we are actually done what we've done, right.
And for the verity part, it's pretty well handled, because if you have this like verity has to say on your kernel command line, that's going to be measured, right.
If you have it in the UK, it's going to be measured this part of PCR 11. If it's not, it's like an extension, it's going to measure it like PCR 12. This is good.
Then, we have a feature in system D, which measures luxury when you mount a partition in the PCR 15, right, with machine ID, which is randomly generated, it makes it a little bit funny in the attestation, because you need to predict that not predict, but know what's good, what's bad, right.
And it's, it's okay, right, we can rely on that, but then, like think about like self-encryption, the use case is, you would for the first time you create some partition.
Maybe it's like overlay over your root partition, or even like a data disk, it doesn't really matter.
So, on the first boot you want to create it, you have an empty disk you created. On all the consecutive boots you just want to mount it, right.
And again, like you're relying like you on the TPM, that it's will be able to unlock it. But think about this attack, like an evil host instead of giving you like an empty disk,
to create a partition, they are with a non-molex master key, and gives it to your guest. And your guest now thinks that it's booting for the second time, right. Oh, the partition's already created, I can just use it, right.
But the host has a lox master key, so it can quickly like decrypted and know what you're putting there.
We want to add the feature to basically capture the encrypted environment, to be able to prove that this encrypted volume was actually created in the same environment.
And I have a proposal, it's not many feedback so far, but there's some system people in the room who can help me with that.
So the idea is let's try to capture, do like a PCR quote at the time when we are creating the encrypted disk, and let's put it somewhere.
You can go inside the disk itself, or it can even go to some, I don't know, like if I system partition for example, because it's not like a secret, right. It's a silent thing that nobody will be able to forge it.
Then we can use it next time when we boot, we say, okay, like if we are not creating it, then there needs to be a quote, which proves that this disk was created in a good, trusted environment and not somewhere else.
Okay, one more thing is that even we have this like full disk encryption in the title of the talk, it can't really be full, right, because you need to be able to boot from somewhere, right.
And like normally in UFI booted systems, you have like UFI system partition, which is just like VFAT, right, it's like Windows thingy.
And it kind of have like integrity or encryption or anything.
So what do you normally rely on things like secure boot and measure boot, and I see somebody like secure boot over there.
So you normally use a thing called like UTI, right, which you want to have signed, and you have key for it, say, in your secure boot database, then you will want to have some extensions.
For example, if you have a variety hash, like how do I do I rebuild my food like UTI with this variety hash or what do I do, normally the answer is, you can comment line extensions, which is based on system desktop.
And also it supports, I mean, like system desktop supports, adding system the system and configuration extensions, which can extend either like slash user or slash it is so of your like, in your trauma fast, so if you want to have like customized in your trauma fast and still want to make it like, again, a testable and secure, then you can use this and sign them.
Okay, so one more thing I wanted to talk about is using this workshop to you guys because like you guys are great will like them, and we think that they give a lot of will you when they are coming from your operating system vendor.
This way you can avoid the hassle of issuing your own secure boot keys and putting them in your secure boot DB, right, you can just say, okay, I trusted my UTI is coming from this operating system vendor, right, and as I just told you, you can then use things like command line extensions and like system system extensions to modify your behavior to set the expected hashes, for example, or to even do this like self encryption on the first boot.
We also have one feature we are working on and it fortunate not getting that much attention upstream so it's been there for like a couple months that.
For the distros which use DRACAT and these are like fedora rail base distros, but some others are using it to.
You may want to hook some like DRACAT action something and currently they DRACAT have them in like var, right, and this kind of big standard with system system extensions, so.
I'm proposing that we also have these hooks in like CTC and flash user, so they can actually be extended by system system and configuration extensions, so this can all work effortlessly.
And that was basically it I know it's like a lot of pictures something I put all the links I tried uploading slides, they were not there when I started talking maybe they're already there, so if you are interested please follow and I'm also interested in all the feedback.
Do we still have time for questions? Okay, so questions go ahead.
Yes, the question is whether it's like VTP and which ties it all to the coca attestation, so yeah, basically if you want to use a traditional operating system in a coca environment, you likely want to rely on the VTP because that's the.
The pacifying standard let's put it this way right we may like it or not like it, but we don't have anything else right.
You may rely purely on like hardware attestation like the initial launch digest something, but that's hard because this launch digest is what the measurement of your like firmware and like.
How can you put your own firmware in a confidential guesthouse on a cloud right that's not available today maybe available in the future when somebody comes with like where you're on firmware.
So yes, this relies on the VTPM and in this scenario you are kind of like trust in the implementation of the VTPM that if it's state full that you're trusting the procedure to basically preserve its state.
And then it's up to you whether you trust some particular cloud vendor how it's doing it some they have different approaches some just say like.
You cannot access the host where it's implemented so it's secure some say okay we're going to do some early you follow list like you find firmware attestation and that's kind of going to get the state but yes it all relies on the VTPM.
One more or not.
Small one yes.
For integrity, that's mostly like this like H max SHA to 56 by default that's implemented in this distributed apart feature but it's actually tunable.
I don't particularly play with it myself right yeah so.
I yeah so if you're very using this age I don't I don't particularly play with it myself right yeah so.