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