WEBVTT 00:00.000 --> 00:15.000 Hello everyone, my name is Vitali, today was me, I have, oh, it's actually not only for 00:15.000 --> 00:16.000 the good fortune. 00:16.000 --> 00:25.000 I have Aminole, we are both from Red Hat, we are from the platform development, so we are 00:25.000 --> 00:30.000 taking part in development like Fedora and Rao, I have had, and today here we are going 00:30.000 --> 00:37.000 to talk about confidential computing guests and in particular how you can actually make a 00:37.000 --> 00:41.000 confidential storage for it. 00:41.000 --> 00:51.000 So, a consortia computing has been a while, you know, hardware vendors came up with 00:51.000 --> 00:52.000 a lot. 00:52.000 --> 00:57.000 So, I don't think I need to explain them a lot. 00:57.000 --> 01:03.000 You can nowadays quickly get a confidential V, which is going to be called confidential from 01:03.000 --> 01:10.000 say major cloud providers, all three big, like Azure, Google, AWS, they all give you 01:10.000 --> 01:16.000 this option, so it's basically click-click and you will get something which is called 01:16.000 --> 01:22.000 the confidential VM, but then if you look at what these technologies really give you, 01:22.000 --> 01:29.000 they give you like memory encryption, memory consistency, CPU register protection, but 01:29.000 --> 01:36.000 there is nothing there about the storage, right, from where your operating system boot, 01:36.000 --> 01:41.000 and you know what's there, it's all left to the operating system you run there, right, 01:41.000 --> 01:45.000 so left there, whatever. 02:11.000 --> 02:21.000 Thank you. 02:41.000 --> 02:48.000 . 03:11.000 --> 03:21.000 . 03:41.000 --> 03:48.000 . 04:11.000 --> 04:29.000 And then use in a way that the host cannot actually read the key. 04:29.000 --> 04:35.000 Whatever you are doing with the storage, it needs to be a testable, I call it. 04:35.000 --> 04:40.000 So, you are able to prove to somebody that you actually done that, right, so if you use 04:40.000 --> 04:46.000 like Verity on your root disk, you should be able to prove to somebody, say, hey, here is my 04:46.000 --> 04:52.000 like this year's signed by my TPM, I can prove that I really used it this way. 04:52.000 --> 04:59.000 And also, like, last but not least, the rollback protection, because even though if you are using 04:59.000 --> 05:06.000 something like encrypted on the disk, an able host may try to roll back some parts of this storage for you, 05:06.000 --> 05:12.000 like, a partition, right, think about you install an update, fix some CV, and it will 05:12.000 --> 05:16.000 host just rewards it back, right, so that's also like a risk. 05:16.000 --> 05:24.000 Okay, so now, I'm going to take from here and call us what we are working on, 05:24.000 --> 05:31.000 mostly like in system disk space, but not only. 05:31.000 --> 05:36.000 But Verity, DM Verities, okay, some already. 05:36.000 --> 05:44.000 I just quick summary is integrity checking for block devices, basically it's enforced by the kernel, 05:44.000 --> 05:51.000 and it's basically making sure that the target partition that you want to vary to protect has not been 05:51.000 --> 05:59.000 modified by anything, and practically this means there is another new partition created that 05:59.000 --> 06:06.000 creates a tree of hashes where the leaves in this tree are the actually the hash of each block or 06:06.000 --> 06:12.000 sector inside the target partition, and then there is each parent is the hash of the hash 06:12.000 --> 06:15.000 and so until you get to a root hash. 06:15.000 --> 06:22.000 And there is a rich support in system D for this, for DM Verity, so there is system D 06:23.000 --> 06:27.000 a part is capable of creating automatically dissolved partition. 06:27.000 --> 06:32.000 Verity is a top generator also detects and does this check at boot, and there is 06:32.000 --> 06:37.000 common line support like a root hash and use rash as we'll see later. 06:37.000 --> 06:45.000 And yeah, so the big downside of Verity protection is by design, of course if you 06:45.000 --> 06:50.000 want to maintain that the disk is not the partition not modified, it has to stay 06:50.000 --> 06:51.000 redolly. 06:51.000 --> 06:59.000 So it's you cannot change the partition to anything else once it's mounted as a Verity. 06:59.000 --> 07:07.000 So you can achieve root with root hash, you target the root partition, and of course 07:07.000 --> 07:12.000 is redolly, and there is a possibility at the moment with system D volatile to add 07:13.000 --> 07:15.000 a femoral overlay. 07:15.000 --> 07:21.000 Otherwise there is use rash, which targets only the slashes partition as a Verity. 07:21.000 --> 07:27.000 And this is used in the Hermetic use approach, which is the idea, as we'll see later 07:27.000 --> 07:32.000 that basically the use, you boot with the only the use partition, which is the 07:32.000 --> 07:34.000 M Verity project. 07:34.000 --> 07:40.000 So yeah, from the, so we looked quickly a Verity, and now we look at the 07:40.000 --> 07:43.000 encryption on the other side encryption. 07:43.000 --> 07:47.000 A lot is great because it provides encryption and the read right. 07:47.000 --> 07:53.000 So now we can actually modify the partition because only Verity is pretty useless for a 07:53.000 --> 07:56.000 generic virtual machine use case. 07:56.000 --> 08:02.000 But the issue is if you want to have an encrypted partition like Vitalis at the beginning 08:02.000 --> 08:08.000 each VM instance or volume needs to be automatically encrypted. 08:08.000 --> 08:12.000 And the question is by what, like, do you need to trust some trust and infrastructure 08:12.000 --> 08:20.000 that encrypts it for you or like the goal of also our work is to enable self encryption. 08:20.000 --> 08:27.000 So at the first boot, the VM itself, we start from something and it creates the partition 08:27.000 --> 08:33.000 and encrypt the partition. 08:33.000 --> 08:40.000 Most of the report, of course, supports also lacks, there is the possibility to see 08:40.000 --> 08:42.000 the keys to the VTPM. 08:42.000 --> 08:50.000 And there is integrity protection coming in the version 26, but even though full rollback attacks 08:50.000 --> 08:52.000 are always possible. 08:52.000 --> 08:59.000 And currently there is also a new feature that to ensure that once you create an encrypted volume 08:59.000 --> 09:04.000 it does not get replaced before it's been actually mounted and used. 09:04.000 --> 09:06.000 Maybe you want to add something, huh? 09:06.000 --> 09:10.000 Yeah, I can elaborate a little bit on this feature. 09:10.000 --> 09:14.000 So for the Verity protection, oh, no. 09:14.000 --> 09:19.000 For integrity protection of a lacks device, it's a built feature of like crypt setup. 09:19.000 --> 09:23.000 And it's there for quite a while, I think, like five years or so. 09:23.000 --> 09:26.000 And still stays experimental. 09:26.000 --> 09:32.000 One of the reasons it's experimental because there was no support for it in the user space. 09:32.000 --> 09:36.000 I don't know, many users enable it. 09:36.000 --> 09:42.000 We want to change that and the first thing we've introduced an option to SystemD 09:42.000 --> 09:49.000 Repart to exige and rate Verity integrity information for the created partition. 09:49.000 --> 09:56.000 With fixating the lacks key, it's quite interesting because I think about the use case, right? 09:56.000 --> 09:59.000 You boot and you want to create a lacks partition, right? 09:59.000 --> 10:01.000 So you're like, okay, here is an empty partition. 10:01.000 --> 10:03.000 I'm going to get run like crypt setup against it. 10:03.000 --> 10:07.000 I'm going to seal the key to the TPM with my current values. 10:07.000 --> 10:09.000 And then I'm going to mount it. 10:09.000 --> 10:15.000 The problem is that if you have like an evil host, it can actually replace the whole lacks volume 10:15.000 --> 10:16.000 right after you create it. 10:16.000 --> 10:21.000 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. 10:21.000 --> 10:23.000 You don't need anything else. 10:23.000 --> 10:26.000 So how do you do it, right? 10:26.000 --> 10:33.000 So this feature looks small, but it allows you to basically capture the snapshot of the lacks key when you're creating it, 10:33.000 --> 10:35.000 but it's still a memory. 10:35.000 --> 10:37.000 And the memory in cocaugust is still protected. 10:37.000 --> 10:43.000 And then you can be sure that you're actually mounting the volume which you've just created and not something else. 10:43.000 --> 10:53.000 Yeah, so to continue the goal is to put these two concepts together. 10:53.000 --> 10:58.000 So where it is together with encryption to get the full read bright experience. 10:58.000 --> 11:02.000 So the idea, there are three different ways to do it. 11:02.000 --> 11:04.000 The first is very basic. 11:04.000 --> 11:09.000 So you copy everything from the very protected volume to the encrypted one. 11:09.000 --> 11:13.000 So when you boot, it's too trivial. 11:13.000 --> 11:17.000 And also it takes probably time if we talk about the route is copying everything. 11:17.000 --> 11:20.000 Then there is the using on overlay. 11:20.000 --> 11:24.000 So basically the idea is that you put, you still mount the very partition. 11:24.000 --> 11:32.000 You put an overlay that, so that every brights on the variety partition gets redirect to the encrypted partition. 11:33.000 --> 11:41.000 And then there is also this interesting idea of the mclone, which is basically on the background, 11:41.000 --> 11:46.000 the copies from the very partition to the encrypted volume. 11:46.000 --> 11:52.000 And while it does, you can still use the disk normally. 11:52.000 --> 11:55.000 So go ahead. 11:55.000 --> 12:01.000 Yeah, so as I said before, there are two way, like at the moment, it's support. 12:01.000 --> 12:05.000 Verity targets the route and the user in system D. 12:05.000 --> 12:16.000 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. 12:16.000 --> 12:23.000 Need automatically system D is able to automatically found the route partition and also the very partition. 12:23.000 --> 12:28.000 So it verifies that the hash should match and it's mounted. 12:28.000 --> 12:34.000 And but currently this cannot be combined with the persistent overlay. 12:34.000 --> 12:36.000 There is only the volatile option. 12:36.000 --> 12:47.000 It should also make sense because in the general use case, if you have, for example, IO, IO workloads with overlay is not ideal. 12:47.000 --> 12:52.000 On the other side, there is use ratio which only handles the use partition. 12:52.000 --> 13:00.000 And here is where we are working on to handle, like, we try to follow the romantic approach. 13:00.000 --> 13:06.000 So you boot with all these, as partition, which should have all the necessary files. 13:06.000 --> 13:08.000 It's DM verity. 13:08.000 --> 13:16.000 Then the route is created by system D report and encrypted at first boot, which is pretty fast because it's an empty partition. 13:16.000 --> 13:19.000 And this also handle already by system D report. 13:19.000 --> 13:29.000 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. 13:29.000 --> 13:33.000 And the rights ends up in the encrypted partition. 13:33.000 --> 13:40.000 And this way, the overlay only covers the less use, which should be better ideally. 13:40.000 --> 13:46.000 Yeah, and then Vitali, we'll talk about the include. 13:47.000 --> 14:02.000 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. 14:02.000 --> 14:13.000 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. 14:14.000 --> 14:24.000 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. 14:24.000 --> 14:36.000 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. 14:36.000 --> 14:41.000 They are probably following some guidelines or some certifications tenders. 14:41.000 --> 14:49.000 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. 14:49.000 --> 14:53.000 It's just like written there, and this user's, we want this because it's written here, right. 14:53.000 --> 15:00.000 So, you cannot put all this overlays on the single partition. You will need to create as many overlays as you have partitions. 15:00.000 --> 15:07.000 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. 15:07.000 --> 15:13.000 So, we are also looking at the thing called DM clone, and I don't know how many of you like have seen it. 15:13.000 --> 15:25.000 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. 15:25.000 --> 15:34.000 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. 15:34.000 --> 15:42.000 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. 15:42.000 --> 15:50.000 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. 15:50.000 --> 16:02.000 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. 16:02.000 --> 16:19.000 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. 16:19.000 --> 16:28.000 So, next, if you remember, I told you that whatever we are doing with the storage needs to be accessible. 16:28.000 --> 16:36.000 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. 16:36.000 --> 16:48.000 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. 16:48.000 --> 16:58.000 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. 16:58.000 --> 17:19.000 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. 17:19.000 --> 17:32.000 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. 17:32.000 --> 17:37.000 Maybe it's like overlay over your root partition, or even like a data disk, it doesn't really matter. 17:37.000 --> 17:44.000 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. 17:44.000 --> 17:56.000 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, 17:56.000 --> 18:10.000 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. 18:10.000 --> 18:16.000 But the host has a lox master key, so it can quickly like decrypted and know what you're putting there. 18:16.000 --> 18:30.000 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. 18:30.000 --> 18:40.000 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. 18:40.000 --> 18:51.000 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. 18:51.000 --> 19:03.000 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. 19:03.000 --> 19:18.000 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. 19:18.000 --> 19:36.000 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. 19:36.000 --> 19:45.000 And like normally in UFI booted systems, you have like UFI system partition, which is just like VFAT, right, it's like Windows thingy. 19:45.000 --> 19:51.000 And it kind of have like integrity or encryption or anything. 19:51.000 --> 19:59.000 So what do you normally rely on things like secure boot and measure boot, and I see somebody like secure boot over there. 20:00.000 --> 20:22.000 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. 20:22.000 --> 20:38.000 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. 20:38.000 --> 21:07.000 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. 21:08.000 --> 21:26.000 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. 21:26.000 --> 21:55.000 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. 21:56.000 --> 22:06.000 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. 22:07.000 --> 22:15.000 For the distros which use DRACAT and these are like fedora rail base distros, but some others are using it to. 22:15.000 --> 22:27.000 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. 22:27.000 --> 22:41.000 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. 22:41.000 --> 22:56.000 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. 22:56.000 --> 23:01.000 Do we still have time for questions? Okay, so questions go ahead. 23:01.000 --> 23:30.000 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. 23:30.000 --> 23:37.000 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. 23:37.000 --> 23:51.000 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. 23:51.000 --> 24:02.000 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. 24:02.000 --> 24:18.000 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. 24:18.000 --> 24:27.000 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. 24:27.000 --> 24:42.000 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. 24:42.000 --> 24:44.000 One more or not. 24:44.000 --> 24:57.000 Small one yes. 24:57.000 --> 25:08.000 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. 25:08.000 --> 25:18.000 I don't particularly play with it myself right yeah so. 25:18.000 --> 25:28.000 I yeah so if you're very using this age I don't I don't particularly play with it myself right yeah so.