WEBVTT 00:00.000 --> 00:11.000 So, I think I'm supposed to start right the second. So, hi, I'm Leonard. I'm going to 00:11.000 --> 00:15.000 talk about multi-profile APIs and otherwise to supercharge your unified kernel images. 00:15.000 --> 00:21.000 I only got 20 minutes, like everyone else here. I have some slides here to keep myself 00:21.000 --> 00:28.000 short, but it's not a disaster if we don't go through all of them. I really like questions, 00:28.000 --> 00:32.000 but I don't hesitate to ask them. I mean, don't ask them this. I have to answer 00:32.000 --> 00:40.000 the novel, but please interrupt me. So, UKIs. What's that again? UKIs is an acronym 00:40.000 --> 00:45.000 short for unified kernel images. I hope that most of you given that you came to this 00:45.000 --> 00:52.000 devroom already know what that is roughly, but if you don't remember, it's a single 00:52.000 --> 00:59.000 of IP binary consisting of the system you stub, if I stub, a kernel image, a traditional one 00:59.000 --> 01:05.000 and an inner ID, a kernel command line, a device tree, if you need that, a boot 01:05.000 --> 01:09.000 splash, if you want that, and maybe a couple of other things. But the gist is all that 01:09.000 --> 01:14.000 together, and one of the e-binary that's a unified kernel binary. We've wrote a 01:14.000 --> 01:22.000 spec about that. In particular, look at that. You show that it kind of formalizes 01:22.000 --> 01:26.000 a little bit, all of this, and how the sections, like the PE sections, 01:26.000 --> 01:30.000 P-binary sections are supposed to be called. What's the benefit of having UKIs? 01:30.000 --> 01:36.000 Of course, robustness. There's only going to be, like if you boot, the firmware 01:36.000 --> 01:41.000 only needs ultimately, in the best case, only read a single file of the USB 01:41.000 --> 01:45.000 and can boot it, so that's very easy. You can update it very easily, right? 01:45.000 --> 01:50.000 Like because you can put the file in place on a temporary name, and then sync everything 01:50.000 --> 01:54.000 to disk and then rename it and sync it again, and that's a very simple, robust way 01:54.000 --> 02:00.000 how you can update your kernels, which is quite beneficial. So yeah, it's also secure 02:00.000 --> 02:05.000 in the sense that, yeah, if it's one file, you can sign it as a whole, you can 02:05.000 --> 02:11.000 measure it as a whole, and it can be authenticated by regular firmware, 02:11.000 --> 02:17.000 UFI firmware, authentication, like secure boot stuff, and maybe even 02:17.000 --> 02:22.000 shim them if you have them in between. So, this is all as great. 02:22.000 --> 02:26.000 I think I did talk about this last year or something, so I kind of hope that 02:26.000 --> 02:30.000 everybody knew everything I had on my slides here before already. 02:30.000 --> 02:34.000 So, what I'm going to talk to today about is about the issues with that design, 02:34.000 --> 02:36.000 right? Like I mean, it's a fantastic design, gives you all the 02:36.000 --> 02:39.000 reproducibility, all the business, all the security, and things like that. 02:39.000 --> 02:43.000 But it comes at a certain drawbacks. It's not really locally, 02:43.000 --> 02:47.000 locally, modifiable. It's a strictly uniform image. 02:47.000 --> 02:51.000 Like, whenever you deploy this, it's going to be the same thing everywhere, 02:51.000 --> 02:54.000 and because of all the security properties of the measurements and of all the 02:54.000 --> 02:58.000 the authentication by a circuit boot, local modifications are not possible. 02:58.000 --> 03:02.000 That's great for many use cases, but it's tellable for many others. 03:02.000 --> 03:06.000 In particular, like, people on, like hackers in particular, 03:06.000 --> 03:12.000 are kind of more used to changing things locally. So, yeah, we try to figure out. 03:12.000 --> 03:15.000 So, yeah, in one hand, we have this beautiful uniform thing, but on the other hand, 03:15.000 --> 03:19.000 people want to make modifications, how do we kind of make that possible? 03:19.000 --> 03:21.000 We came up with a couple of solutions. 03:21.000 --> 03:25.000 Like, the first one is, yes, I add-ons, like Luca added that mostly. 03:25.000 --> 03:32.000 On the EFI add-ons, basically, these little P files that look like executables, 03:32.000 --> 03:37.000 but actually do not contain any code. They are just envelopes with all the other stuff 03:37.000 --> 03:40.000 that had on the earlier slides. Like, for example, Nickstra in it already. 03:40.000 --> 03:43.000 Nickstra, kind of command line. It's mostly about the kind of command line, 03:43.000 --> 03:45.000 but it can also carry the other stuff. 03:45.000 --> 03:48.000 CPU microcode or whatever else. 03:48.000 --> 03:51.000 They are authenticated because they are P binary. 03:51.000 --> 03:56.000 They are authenticated, like, like, any P binary, like, second blue version. 03:56.000 --> 04:01.000 Yeah. So, this is a solution number one to this problem. 04:01.000 --> 04:05.000 There's another solution that we came up with. It's called system decradentials. 04:05.000 --> 04:10.000 They are not authenticated by second blue and shim, but by TPN. 04:10.000 --> 04:13.000 And it's for parameterization of systems and services. 04:13.000 --> 04:15.000 Like, this is inherently a system to be concept. 04:15.000 --> 04:19.000 We basically have this little bits of data that have name, 04:19.000 --> 04:22.000 and that can, like, you lock to the local TPN. 04:22.000 --> 04:26.000 And that can, like, they are encrypted and authenticated by the TPN. 04:26.000 --> 04:28.000 And then they are unlocked. 04:28.000 --> 04:34.000 The moment the service that consumes them is going to start. 04:34.000 --> 04:39.000 This is great for stuff you need later, right? 04:39.000 --> 04:41.000 Like, because you need a system D instance running. 04:41.000 --> 04:44.000 And the authentication and decryption happens at the moment. 04:44.000 --> 04:48.000 This is used, right? Like, or the service that actually wants to consume them is used. 04:48.000 --> 04:55.000 Which is different from the EFI add-on stuff, which is authenticated during early boot when it's first loaded. 04:55.000 --> 04:58.000 And then solution number three is also a system thing. 04:58.000 --> 05:01.000 This thing is a system with context and system usage, 05:01.000 --> 05:04.000 which are, like, authentic and kernel keering. 05:04.000 --> 05:06.000 And they are basically little disc images. 05:06.000 --> 05:08.000 And you can overlay over that scene user. 05:08.000 --> 05:11.000 And where you can not just have little bits of information, 05:11.000 --> 05:13.000 but you can actually add, like, a bunch of files, 05:13.000 --> 05:15.000 autonomically to that scene user tree. 05:15.000 --> 05:17.000 So, I'm not going to talk much about this here, 05:17.000 --> 05:19.000 but I want to talk to those to be about this. 05:19.000 --> 05:21.000 It's about what the other stuff. 05:21.000 --> 05:22.000 So, this is all great. 05:22.000 --> 05:25.000 Conceptually, all of these are side cars. 05:25.000 --> 05:28.000 If you're so well, right? Like, you have your UK. 05:28.000 --> 05:30.000 That's nicely uniform in a single file. 05:30.000 --> 05:33.000 And then you drop next to it in a sub directory that is named exactly like the UK. 05:33.000 --> 05:36.000 Just with the D at the end, the side cars. 05:36.000 --> 05:41.000 And then the SD stub thing that is glued in front of the UK. 05:41.000 --> 05:46.000 Goes and looks next to itself, basically, for these files, loads them into memory. 05:46.000 --> 05:49.000 If it's the EF, I add on it. 05:49.000 --> 05:53.000 Pull a sandicate them by a regular second boot. 05:53.000 --> 05:55.000 The other stuff it puts up in an inner audience, 05:55.000 --> 05:57.000 a positive crown. 05:57.000 --> 05:59.000 So, yeah. 05:59.000 --> 06:03.000 They extend your kind of pretty flexible session. 06:03.000 --> 06:08.000 Like, a second boot chim kind of means that everything is bound to your distribution keys. 06:08.000 --> 06:12.000 So, and the system credentials are kind of authenticated by, 06:12.000 --> 06:14.000 by inherently local stuff. 06:14.000 --> 06:18.000 And we confess this stuff by whatever is in the kernel curing. 06:18.000 --> 06:24.000 So, these are different, like, owners of the authentication mechanisms. 06:24.000 --> 06:25.000 But, yeah. 06:25.000 --> 06:26.000 Still, it's pretty flexible. 06:26.000 --> 06:31.000 This stuff, inherently local, this stuff, then a bound. 06:31.000 --> 06:32.000 Yeah. 06:32.000 --> 06:35.000 Might talk today, so far any questions. 06:35.000 --> 06:38.000 So, now we're going to start with the actually interesting stuff. 06:38.000 --> 06:39.000 Okay. 06:39.000 --> 06:42.000 So, multi-profile e-cards, something I recently added to system D. 06:42.000 --> 06:45.000 I mean, I think the year ago something I started working on this, 06:45.000 --> 06:47.000 which is the fourth solution to this. 06:47.000 --> 06:49.000 And it's new. 06:49.000 --> 06:53.000 The idea, basically, is that we can have a little bit of variability 06:53.000 --> 06:56.000 in what you actually boot there. 06:56.000 --> 06:59.000 But, you still do it within that single e-KI. 06:59.000 --> 07:03.000 So, you do not have side cards for the first time, 07:03.000 --> 07:05.000 but you actually do it within the e-KI. 07:05.000 --> 07:08.000 So, you basically have multiple profiles. 07:08.000 --> 07:12.000 And the sense basically is that you have operative sections, 07:12.000 --> 07:15.000 like previously traditional e-KI's. 07:15.000 --> 07:16.000 You have one of each. 07:16.000 --> 07:19.000 Like, you have one internally, one kernel command line, 07:19.000 --> 07:21.000 one device, three and so on. 07:21.000 --> 07:26.000 With multi-profile e-KI's, we basically allow you to have many of these. 07:26.000 --> 07:28.000 And then you glue them together in a profile, 07:28.000 --> 07:31.000 or in another profile, or in a third profile. 07:31.000 --> 07:33.000 So, yeah. 07:33.000 --> 07:36.000 Not a side card, but all inside of the e-KI. 07:36.000 --> 07:38.000 It's still authenticated as one. 07:38.000 --> 07:40.000 It's copied in as one. 07:40.000 --> 07:42.000 It's just one file. 07:42.000 --> 07:45.000 It provides a much more limited flexibility, 07:45.000 --> 07:47.000 like because the person, 07:47.000 --> 07:51.000 who, or the vendor who puts together e-KI, 07:51.000 --> 07:53.000 I need to just think about all the options beforehand. 07:53.000 --> 07:56.000 And then define a few blessed configurations, 07:56.000 --> 07:58.000 basically, that are a combination of kernel, 07:58.000 --> 08:02.000 in a dirty kernel command line and so on. 08:02.000 --> 08:05.000 I think most of the time profiles are probably going to be used 08:05.000 --> 08:08.000 for the, just for the kernel command line, 08:08.000 --> 08:11.000 like so that they all share the same kernel, same inner dirty, 08:11.000 --> 08:15.000 same everything else, but then have a separate kernel command line 08:15.000 --> 08:17.000 that is a little bit different from the others. 08:17.000 --> 08:18.000 But yeah. 08:18.000 --> 08:21.000 Primary use case is that you have one UKI, 08:21.000 --> 08:23.000 that with a couple of different kernel command lines, 08:23.000 --> 08:26.000 one for regular boots, one for recovery mode, 08:26.000 --> 08:28.000 one for factory set, one for storage target mode, 08:28.000 --> 08:29.000 and these kind of things. 08:29.000 --> 08:32.000 Like so, where you basically boot the OS, 08:32.000 --> 08:33.000 mostly the same way, 08:33.000 --> 08:35.000 except that you actually boot it to a different target 08:35.000 --> 08:37.000 that has a different purpose. 08:37.000 --> 08:40.000 It could be also installed or stuff, whatever else. 08:40.000 --> 08:42.000 Like what people will come up with, 08:42.000 --> 08:43.000 how they want to use this up to them. 08:43.000 --> 08:45.000 Of course, these are just the obvious ideas 08:45.000 --> 08:47.000 that came to my mind. 08:47.000 --> 08:50.000 Systemly boot, you know. 08:50.000 --> 08:53.000 Systemly stuff is that if I stop that I talked about, 08:53.000 --> 08:57.000 systemly boot is the boot menu thingy that runs before it, 08:57.000 --> 08:58.000 if you want this, 08:58.000 --> 09:01.000 it has been updated to understand these profiles, right? 09:01.000 --> 09:03.000 So if you, like traditionally, 09:03.000 --> 09:05.000 if you drop a UKI and then one directory, 09:05.000 --> 09:08.000 systemly boot will find it and put it in the boot menu, 09:08.000 --> 09:11.000 it can choose from the menu and boot it. 09:11.000 --> 09:14.000 System boot has now been updated to understand the profiles. 09:14.000 --> 09:15.000 So you drop in that one file, 09:15.000 --> 09:17.000 it has five profiles or something like this, 09:17.000 --> 09:22.000 and SD boot will understand and create five menu entries from that, right? 09:22.000 --> 09:24.000 One for each of the profiles. 09:24.000 --> 09:26.000 These profiles come with a little bit of metadata, 09:26.000 --> 09:28.000 so that you can actually put a nice string on the menu item 09:28.000 --> 09:31.000 that is called actually recovery mode, 09:31.000 --> 09:34.000 instead of profile time a suite. 09:34.000 --> 09:40.000 Which profile you actually choose to boot is measured to a TPMPCR, 09:40.000 --> 09:42.000 so that we have all the security properties, right? 09:42.000 --> 09:45.000 This slide might be a little bit confusing. 09:45.000 --> 09:50.000 It's the SD stuff, not SD boot that actually does the measurement of the profile, right? 09:50.000 --> 09:54.000 So you can actually use profiles even without a systemly boot. 09:54.000 --> 09:56.000 If you do direct firmware to UKI, 09:56.000 --> 10:02.000 I would mention being because that in the command line and then load options, 10:02.000 --> 10:05.000 then you can configure in UFI. 10:05.000 --> 10:08.000 Because this is just one UKI, 10:08.000 --> 10:10.000 you get the regular authentication by a secure boot, 10:10.000 --> 10:11.000 and stuff like that, 10:11.000 --> 10:14.000 and you get the measurements of the PCR, 10:14.000 --> 10:16.000 like in PCR4 and things like that. 10:16.000 --> 10:21.000 The measurements that SD stuff does will only cover the profile, 10:21.000 --> 10:23.000 they actually choose though, right? 10:23.000 --> 10:27.000 It's important so that, yeah, only the stuff actually consumed 10:27.000 --> 10:30.000 is the stuff that actually shows up in the measurement logs, 10:30.000 --> 10:35.000 and you can very clearly distinguish which of the profiles was actually chosen. 10:35.000 --> 10:37.000 This kind of stuff matters because you, like for example, 10:37.000 --> 10:39.000 for storage target mode, right? 10:39.000 --> 10:42.000 Like this mode where basically, 10:42.000 --> 10:47.000 like mecos had that for a long time where you can boot into a mode where 10:47.000 --> 10:50.000 your heart is exposed as ice-cuzzing in that case, 10:50.000 --> 10:55.000 but it's like system natively supported by NVMe because it's very easy to do that 10:55.000 --> 10:56.000 with a kernel. 10:56.000 --> 10:59.000 But in that case, you don't want that full description work, right? 10:59.000 --> 11:01.000 Like you want to expose the disk as the disk, 11:01.000 --> 11:03.000 not as a decrypted disk, right? 11:03.000 --> 11:06.000 So it's important for different profiles, 11:06.000 --> 11:09.000 you can have different security, 11:09.000 --> 11:13.000 policy objects that you can bind to, 11:13.000 --> 11:16.000 so that you can say, yeah, if I put in storage target mode, 11:16.000 --> 11:18.000 do make it impossible to unlock the disk, 11:18.000 --> 11:21.000 but if you boot in regular mode, make it possible. 11:21.000 --> 11:26.000 Systemly measure, like that's this little tool that can pre-calculate 11:26.000 --> 11:32.000 the measurements that booting a UKI will result in natively support set. 11:32.000 --> 11:34.000 UKI, like that's our tool, 11:34.000 --> 11:36.000 Python tool, a part of system, 11:36.000 --> 11:38.000 that helps you with building UKI's, 11:38.000 --> 11:41.000 has been updated to support these multiple profiles. 11:41.000 --> 11:43.000 UKI's, and I already mentioned that profiles carry this 11:43.000 --> 11:45.000 extensible descriptive metadata. 11:45.000 --> 11:46.000 It's used for many items rings, 11:46.000 --> 11:48.000 but we can later use it for other stuff as well. 11:48.000 --> 11:51.000 Like, for example, there are some ideas about adding a little bit 11:51.000 --> 11:52.000 of matching to that too, 11:52.000 --> 11:55.000 so you can suppress a couple of menu items that are applied 11:55.000 --> 11:57.000 to the local system, or something like that. 11:57.000 --> 12:00.000 So much about profile, UKI's, 12:00.000 --> 12:02.000 anyone has a question about this port, you have. 12:02.000 --> 12:05.000 The profile is the section in the, 12:05.000 --> 12:08.000 is it a combination of six sections? 12:08.000 --> 12:10.000 So the question was regarding what a profile is, 12:10.000 --> 12:14.000 is it is a section itself in the executable or a combination of sections? 12:14.000 --> 12:19.000 So it's a, like, there is a section type called .profile, 12:19.000 --> 12:22.000 and it carries the metadata, 12:22.000 --> 12:26.000 but it just combines a couple of other sections 12:26.000 --> 12:28.000 that are exactly like the previous, like, 12:28.000 --> 12:30.000 a highlight at all always was. 12:30.000 --> 12:32.000 So, basically, if you have three profiles 12:32.000 --> 12:34.000 that all want to use the same kernel, 12:34.000 --> 12:36.000 the kernel's only their ones. 12:36.000 --> 12:39.000 So, yeah, it's about like, 12:39.000 --> 12:43.000 you only have additional copies of the stuff 12:43.000 --> 12:46.000 that you actually want to change in each profile. 12:46.000 --> 12:48.000 There is another question. 12:48.000 --> 12:53.000 So the question was like, 12:53.000 --> 12:57.000 how do you actually pick the profile from system to boot in the firmware? 12:57.000 --> 12:59.000 Like, from system to boot, I already mentioned this, 12:59.000 --> 13:02.000 like, you just have five menu items, 13:02.000 --> 13:04.000 and pick the one that you want, 13:04.000 --> 13:07.000 because, yeah, one UKI will create five menu items. 13:07.000 --> 13:11.000 This is then propagated to the UKI via the load options thing, 13:11.000 --> 13:14.000 so basically the command line, if you're so well. 13:14.000 --> 13:17.000 And, but it's actually a little bit tricky, right? 13:17.000 --> 13:20.000 Like, because we don't necessarily want, 13:20.000 --> 13:23.000 like, we don't want to measure it together with the command line, 13:23.000 --> 13:25.000 so we actually chop it off before the measurement 13:25.000 --> 13:26.000 and think like that anyway. 13:26.000 --> 13:28.000 It probably, the details are a little bit too complicated, 13:28.000 --> 13:29.000 this question. 13:29.000 --> 13:30.000 But, long story short, 13:30.000 --> 13:32.000 if you want to select it from directly, 13:32.000 --> 13:34.000 if you do not use SD boot, 13:34.000 --> 13:36.000 but want to boot directly from firmware into a UKI, 13:36.000 --> 13:39.000 you also put it in the load options, right? 13:39.000 --> 13:43.000 But it doesn't look like a command line switch on purpose, 13:43.000 --> 13:46.000 like with the add symbol, 13:46.000 --> 13:49.000 so that I make very clear that this is not considered 13:49.000 --> 13:51.000 a regular command line option, right? 13:51.000 --> 13:53.000 Like, it's a psychological thing. 13:53.000 --> 13:57.000 Anyway, no more questions about there's another one. 13:57.000 --> 13:59.000 So, do you mind to imagine being kind of scared about 13:59.000 --> 14:00.000 that is independent of this? 14:00.000 --> 14:01.000 Yeah. 14:01.000 --> 14:03.000 So, the question was regarding whether 14:03.000 --> 14:05.000 the advisory matching is independent of this, 14:05.000 --> 14:07.000 obviously you know this. 14:08.000 --> 14:10.000 Yeah, it's entirely independent, right? 14:10.000 --> 14:13.000 Like this is mostly about selecting 14:13.000 --> 14:18.000 like the focuses on giving the user a choice of different profiles. 14:18.000 --> 14:20.000 It's not so much about making automatic choice, 14:20.000 --> 14:23.000 we have some other stuff in store for that. 14:23.000 --> 14:25.000 So, my next slide is actually about this. 14:25.000 --> 14:27.000 Otherwise, do supercharge UKI. 14:27.000 --> 14:29.000 So, this is something that we recently added as well 14:29.000 --> 14:31.000 as an automatic choice of device trees, right? 14:31.000 --> 14:33.000 Like, because on ARM devices, you usually want to support 14:33.000 --> 14:34.000 more than one ARM device, 14:34.000 --> 14:36.000 and they all need slightly different device trees. 14:36.000 --> 14:41.000 So, somebody whose name I forgot added this logic 14:41.000 --> 14:46.000 to SD stuff to actually do allow you to have multiple device tree 14:46.000 --> 14:48.000 blobs in the same UKI. 14:48.000 --> 14:52.000 And then at boot, we calculate a hash from DMI data 14:52.000 --> 14:55.000 like the Microsoft hardware ID stuff, 14:55.000 --> 14:58.000 CHID, is used for this. 14:58.000 --> 15:00.000 And that picks the right one for the local system. 15:00.000 --> 15:02.000 So, that you can basically have one unified UKI, 15:02.000 --> 15:04.000 the carry 77 device trees, if you're as well 15:04.000 --> 15:07.000 and the right one for your local system is actually used. 15:07.000 --> 15:11.000 The sections, called differently than they were traditionally, 15:11.000 --> 15:16.000 these ones called DTB author instead of DTB. 15:16.000 --> 15:18.000 I forgot DTB, right? 15:18.000 --> 15:20.000 To indicate that there's only one of them 15:20.000 --> 15:22.000 chosen and it's automatic. 15:22.000 --> 15:27.000 There's a second section type called HWIDs. 15:27.000 --> 15:30.000 That's the part that actually contains the tables 15:30.000 --> 15:36.000 like based on which hardware IDs pick which device tree. 15:36.000 --> 15:40.000 Yeah, it's basically really stupid mapping from the Microsoft 15:40.000 --> 15:41.000 CHID. 15:41.000 --> 15:43.000 I don't know how I'm pronouncing it. 15:43.000 --> 15:49.000 CHID, like from the Microsoft shed to the device tree 15:49.000 --> 15:50.000 compatible string. 15:50.000 --> 15:53.000 This is automatically selected by boot by system DTB. 15:53.000 --> 15:56.000 It's not a user selection in this case. 15:57.000 --> 16:01.000 This guy, I'm on here, who just asked this question, 16:01.000 --> 16:04.000 then it's adding something right now, 16:04.000 --> 16:06.000 like he got the most, like the key part's merge, 16:06.000 --> 16:07.000 but it's not completely yet. 16:07.000 --> 16:09.000 I'll bring you on firmware. 16:09.000 --> 16:11.000 This is for confidential computing and stuff. 16:11.000 --> 16:14.000 They kind of want us that the firmware, 16:14.000 --> 16:17.000 like the UKI, can have control about the firmware 16:17.000 --> 16:18.000 that's actually used. 16:18.000 --> 16:20.000 So, the idea is basically that you leverage 16:20.000 --> 16:23.000 the same logic as the device tree selection. 16:23.000 --> 16:26.000 And that I firmware in UKI. 16:26.000 --> 16:29.000 You drop that on your confidential computing VM. 16:29.000 --> 16:31.000 When it boots out of the checks, 16:31.000 --> 16:33.000 the firmware is actually running on the same one as 16:33.000 --> 16:34.000 the one that it carries. 16:34.000 --> 16:36.000 If so, it's just continue booting normally. 16:36.000 --> 16:37.000 Like it always did. 16:37.000 --> 16:41.000 If not, it will issue those EFI calls to update the firmware. 16:41.000 --> 16:42.000 We'll reboot. 16:42.000 --> 16:45.000 We'll come back and then we'll have the right firmware. 16:45.000 --> 16:48.000 So, this is basically the idea is that if this is in place, 16:48.000 --> 16:52.000 you can have your UKI for some, 16:53.000 --> 16:55.000 confidential computing VM. 16:55.000 --> 17:00.000 And you, afterwards, have the guarantee and the TPM measurements. 17:00.000 --> 17:05.000 And so, prove this to you that you're running only the software 17:05.000 --> 17:08.000 that you wanted to run on it, including the firmware. 17:08.000 --> 17:12.000 So, it's kind of nice that we can reuse the same thing 17:12.000 --> 17:15.000 that the device tree people did for embedded devices 17:15.000 --> 17:17.000 for bringing it on firmware. 17:18.000 --> 17:22.000 This is basically a new section called .EFI, 17:22.000 --> 17:24.000 FW, which carries the firmware. 17:24.000 --> 17:29.000 And then we use the .HW IDs that we already have 17:29.000 --> 17:31.000 for the device tree stuff to do the mapping again. 17:31.000 --> 17:33.000 And as automatically chosen, 17:33.000 --> 17:36.000 so that you can actually have one UKI that works on the 17:36.000 --> 17:38.000 confidential computing environments, 17:38.000 --> 17:41.000 both of AWS and Microsoft or something like this. 17:41.000 --> 17:42.000 Yeah. 17:42.000 --> 17:45.000 But also interesting about this is that you can now 17:45.000 --> 17:47.000 it is directly booting the UKI on a QMU command line, 17:47.000 --> 17:49.000 so that you can actually test this really nicely. 17:49.000 --> 17:51.000 Because then you basically have one UKI. 17:51.000 --> 17:53.000 You specify the QMU command line, 17:53.000 --> 17:54.000 confidential computing environments, 17:54.000 --> 17:55.000 and boots up, and everything. 17:55.000 --> 17:58.000 There's no other complexity involved anymore. 17:58.000 --> 18:00.000 And you get the perfect guarantee that 18:00.000 --> 18:02.000 yeah, everything inside of the VM, you can trust. 18:02.000 --> 18:04.000 Yeah, there's another talk. 18:04.000 --> 18:07.000 But I'm here in, yeah. 18:07.000 --> 18:08.000 Click on that. 18:08.000 --> 18:10.000 I mean, I'm not sure how you can do this, 18:10.000 --> 18:11.000 but yeah, click on that. 18:11.000 --> 18:12.000 And I follow that targets. 18:12.000 --> 18:13.000 What is it? 18:14.000 --> 18:15.000 Tomar. 18:15.000 --> 18:17.000 Anyway, I only go like, 18:17.000 --> 18:19.000 how much time left? 18:19.000 --> 18:21.000 Two minutes left. 18:21.000 --> 18:24.000 I have some more slides, but I don't matter. 18:24.000 --> 18:27.000 Let's prefer, I would prefer, 18:27.000 --> 18:29.000 for each still use the last two minutes for questions. 18:29.000 --> 18:30.000 There's a question. 18:30.000 --> 18:31.000 Yeah. 18:31.000 --> 18:34.000 How do you experiment with this as a public pilot plan? 18:34.000 --> 18:35.000 A cool bit. 18:35.000 --> 18:37.000 A cool bit. 18:37.000 --> 18:38.000 A cool bit. 18:38.000 --> 18:39.000 A cool bit. 18:39.000 --> 18:40.000 A cool bit. 18:40.000 --> 18:41.000 A cool bit. 18:41.000 --> 18:42.000 A cool bit. 18:42.000 --> 18:44.000 If I have experience with this as a corporate, 18:44.000 --> 18:45.000 I have no experience with this corporate. 18:45.000 --> 18:47.000 You know, I'm this guy who runs this PC. 18:47.000 --> 18:49.000 I only do you if I'm very boring. 18:49.000 --> 18:51.000 Is this what the useful one has to do? 18:51.000 --> 18:53.000 It's like, it's a long split. 18:53.000 --> 18:55.000 I'm pretty sure. 18:55.000 --> 18:57.000 But I have no idea. 18:57.000 --> 19:00.000 So, I mean, the key here is really, 19:00.000 --> 19:02.000 you know, with this stuff, 19:02.000 --> 19:03.000 you don't really need, 19:03.000 --> 19:05.000 like you have basically one file, 19:05.000 --> 19:07.000 particularly the bringing on firmware, 19:07.000 --> 19:09.000 that boots like the whole shit's right. 19:09.000 --> 19:11.000 And that's kind of nice. 19:11.000 --> 19:14.000 I think we have time for one more question. 19:14.000 --> 19:16.000 No one has a question. 19:16.000 --> 19:18.000 Was I so clear? 19:18.000 --> 19:20.000 Come on. 19:20.000 --> 19:23.000 No one has a question. 19:23.000 --> 19:25.000 Nothing. 19:25.000 --> 19:28.000 Did nobody understand what I was saying or what? 19:28.000 --> 19:29.000 No. 19:31.000 --> 19:34.000 I'm a little bit disappointed in you. 19:34.000 --> 19:35.000 Okay. 19:35.000 --> 19:36.000 Then, I guess. 19:36.000 --> 19:38.000 Thank you very much for your time. 19:38.000 --> 19:40.000 I have some other talks. 19:40.000 --> 19:41.000 Yeah. 19:41.000 --> 19:44.000 There's one about, 19:44.000 --> 19:47.000 yeah, that where we will talk about some more stuff. 19:47.000 --> 19:49.000 So, anyway, look at everything schedule. 19:49.000 --> 19:52.000 And yeah, thank you very much.