WEBVTT 00:00.000 --> 00:22.000 So, we can start. So, as you may know, currently, we are mostly focusing on Intel TXT platforms 00:22.000 --> 00:29.960 because this is first implementation on which we are working on and it provides not 00:29.960 --> 00:39.920 only the TXT implementation, but also generic code and structures which will be used for further 00:39.920 --> 00:47.560 development for AMD, ARM, etc. So, this is the key thing which should be introduced into 00:47.560 --> 00:56.720 the kernel itself. As you can see, I think that we are nearing to the point where this 00:56.720 --> 01:05.280 part of this will be taken into the kernel itself. In the meantime, there was introduced 01:05.280 --> 01:11.280 a quick start guide on the transport project because at this point it is quite difficult 01:11.280 --> 01:21.160 to first of all find platforms which work with the transport and the other problem is that 01:21.160 --> 01:29.360 it is quite difficult to configure the software to run this project. So, we have a quick 01:29.360 --> 01:36.400 start guide which guides to you through the process setting up the environment and the software. 01:36.400 --> 01:45.360 Also, we are working on various versions of raw speed working, various versions of implementation 01:45.440 --> 01:55.280 from TXT. There are three releases in last few months, version 10, 11 and 12. In general, 01:55.280 --> 02:01.440 there were mostly discussions recently happening around Shawan and why we are using Shawan 02:01.440 --> 02:10.000 and maybe we will use a different kind of functions to calculate houses from the TPM. So, it 02:10.080 --> 02:20.480 was quite tough discussion, but I think that during reviewing V11, all questions were solved 02:20.480 --> 02:30.240 and rostered V12 and at this point, I think everything will be shortly accepted. But we 02:30.240 --> 02:37.040 can see because there is no error play from the kernel community. We are going to poke some people 02:37.120 --> 02:49.600 into your peoples. Also, the AMD is still under development. In general, we are, of course, 02:49.600 --> 02:57.280 we are basic our development on IntelTXT implementation for year OEMs. So, there are some 02:57.600 --> 03:06.880 things which should be hidden in early stages. From the kernel, it looks that it is possible. 03:06.880 --> 03:17.760 So, the kernel will be quite generic and it will be able to work on various hardware. 03:18.880 --> 03:24.640 So, I hope that it is going quite good direction, but as I said, this is in early stages. 03:24.640 --> 03:32.560 We are focusing mostly on X86 at this point. The group, the group part is also very important 03:32.560 --> 03:44.320 think of the stuff because the crop prepares all the platform for the secure launch. So, it contains 03:44.320 --> 03:54.080 all components which are needed to initialize the platform. And all developments were tied to 03:55.040 --> 04:04.000 mostly at this point to IntelTXT implementation. But, unfortunately, as you may know, we have 04:04.000 --> 04:11.600 values, grap implementation for various distros, distros and also we have upstream. So, initially, 04:11.600 --> 04:19.920 some parts of development were based on downstream staff, some part were based on upstream. 04:20.000 --> 04:27.440 Ross was able to move all this code to the upstream and also free-ended folks, 04:28.960 --> 04:39.200 based some of all this stuff for AMD on the IntelTXT implementation made by Ross. 04:39.200 --> 04:45.040 Also, we were able to make some preparatory parts into the grap upstream. They are just providing 04:45.680 --> 04:54.480 some just cleanups in the code. So, it is just preparation, nothing else. There is no functionality. 04:54.480 --> 05:01.040 When the IntelTXT land in the kernel, then we almost immediately finish reviewing the patches 05:01.040 --> 05:10.080 in the grap and take them into the, into the grap. And also, as I said, 05:10.080 --> 05:17.680 if we am deprovised, AMD's can eat and post it RSC patches on December 18. So, it is 05:17.680 --> 05:23.680 available on the grap developer. You can play with it, test it and send us our reports. 05:23.680 --> 05:29.600 So, it's that's it for my site. Let's move on to my stuff. 05:29.600 --> 05:35.280 Thank you for your time. Any questions? 05:37.360 --> 05:41.680 When we are switching, no. So, we will have more questions after. 05:46.240 --> 05:52.160 Okay, so as I said, I will cover the part that VMDEP has been worked on in the last year. 05:52.960 --> 06:00.160 So, I match it and the engineering manager at VMDEP. Although most of the technical work has been done by 06:00.160 --> 06:05.760 colleagues, mostly Christian, Sergi and others. They also were kind enough to help me with this presentation. 06:07.600 --> 06:12.320 Again, I've pretty simple for today. We present what we've been working on since the 06:12.320 --> 06:21.440 during the last year and what are the future plans. So, we have two main work streams in VMDEP. 06:21.600 --> 06:29.840 On the one side, the first area is implementation of the original DRT and task for AMD 06:29.840 --> 06:36.480 in contrast to the new one. Let's say for which in which Oracle was most invested in. 06:38.480 --> 06:42.240 In this case, we are working on the Linux kernel boot path mostly. 06:43.040 --> 06:49.920 And the second one is practical application of transport as keeps us anti-vmite application. 06:50.480 --> 06:57.120 In this case, we are obviously more focused on the design. Boot path as keeps us using this one. 06:59.600 --> 07:06.240 So, let's start with the first one. So, transport for AMD, let's say, so we have 07:09.520 --> 07:13.920 basically updated the existing code we had to then use version of specification to use 07:13.920 --> 07:19.920 a secure entry resource table. We have also integrated our challenges with the ones from 07:19.920 --> 07:26.560 Oracle. So, we can have a single code base, which would work on the older and newer AMD CPUs. 07:29.120 --> 07:35.360 On top of that, we've been adding some tests to our test suite, which is open-surfing validation. 07:36.560 --> 07:42.640 And we've updated over fresh some of the trend boot documentation with our current development. 07:43.200 --> 07:48.960 There were a huge keynote there, might do during the last year. So, should be more user friendly. 07:51.040 --> 07:56.800 What's also what's now think here is that really wise method transport, 07:56.800 --> 08:04.640 y'all are, it can be used for testing and demonstration. So right now, we can use it to build a single 08:04.640 --> 08:10.720 generic image. It can support at the same time like a case UFI boot. It can support Linux 08:10.800 --> 08:15.200 and the example you can select, you want to test Linux, you want to test Zen, you want to normal, you want to 08:15.200 --> 08:21.680 between 3D boot. It's a part of the Intel AMD. So, you can have a single image that you can use for 08:21.680 --> 08:25.360 evaluation of a hardware, for instance, if you can work with 3D boot. 08:28.960 --> 08:34.880 In terms of plans and what's in progress, it's mostly upstream, we have finalized the main development 08:34.880 --> 08:44.480 in this part. The Linux Intel series has been described by Daniel. We are kind of depending on 08:44.480 --> 08:49.840 that in the Linux kernel as it contains also a common code that AMD Chinese require. 08:51.520 --> 09:00.320 We have successfully submitted a small portion of the graph patches, but there has also 09:00.400 --> 09:06.960 depends on the Linux kernel upstream because we want to have stable Linux first, at least that's the 09:08.160 --> 09:16.320 that the policy in graph right now. Then we have the second one, which is runs boot as 09:16.320 --> 09:25.520 cube stress and Tbilmite solution. So, there are also a couple improvements there. We have finalized 09:25.840 --> 09:36.480 the GAC boot part. We have extended the graph so it can look for all of the disease. So, the 09:36.480 --> 09:42.880 secure kernel folder for AMD and different kinds of ICNs for different Intel micro architecture. 09:42.880 --> 09:47.760 So, user doesn't need to select the proper one, it's selected automatically, which 09:48.640 --> 09:54.560 leads us to more generic image and better user experience. We have some RPM repository that can 09:54.640 --> 10:03.040 be used to ship a kip size packages with trend boot changes. What's in progress? It's advanced, 10:03.040 --> 10:11.360 but it's still not released let's say that we are fine, part with kip size. So, there's a lot of 10:11.360 --> 10:17.200 configuration to play skill as well. So, Intel AMD, with AMD we have to kind of 10:17.280 --> 10:19.280 the RK. 10:25.280 --> 10:30.560 A parent is boring. Or something is not clear. 10:36.640 --> 10:38.640 Oh, we have a cache go ahead. 10:47.280 --> 11:06.000 So, we're asking about booting Kleg AC in the GAC mode. So, as we shown in the GAC part we are 11:06.000 --> 11:12.800 more advanced. So, we could definitely, maybe it's not plug and play because there are 11:13.120 --> 11:20.080 different components, but definitely we could like try this meta-trans boot build and image and 11:20.080 --> 11:25.360 boot it on your specific hardware and see if that works. That's why you can 11:26.160 --> 11:33.040 maybe perhaps the easiest one to try it yourself. You can reach out in as in the nitrix and we can 11:33.040 --> 11:40.240 guide if there is any problem with that, but the GAC mode is definitely more advanced, I would say. 11:42.880 --> 11:50.080 I want to add to this because if I understand correctly we are saying about BIOS implementation. 11:50.640 --> 11:57.840 So, for using mostly on BIOS in implementation of DRTM and Oracle mostly focus on EFI, 11:57.840 --> 12:08.320 but in general the idea is that this DRTM implementation on X86 has to work on both platforms, EFI 12:08.320 --> 12:17.520 and legacy BIOS. This is the approach. So, all these things will be glued together and will work 12:17.520 --> 12:22.400 in delinux and the graph. I hope that this applies your question. Okay, thanks a lot. 12:22.400 --> 12:33.760 Any additional questions? Go ahead. So, how can I test for AMD on legacy? What's that like 12:34.480 --> 12:41.520 easiest to upload on what platform it's easier to upload? I'm not platform. We used to 12:44.240 --> 12:53.440 I have listed here the KGPE and maybe the other one, HP. HP1 is the one we use right now for 12:53.440 --> 13:02.320 there isn't development. It's like stock firmer not anything from us so to speak, but it can be 13:02.400 --> 13:08.640 used for cubes specifically because we had also the other ones like the APU PC engines, but it's not 13:08.640 --> 13:15.840 cubes target, but you can still use the method range boot on PC engines with the color boot 13:15.840 --> 13:26.640 firmer, legacy firmer, but for something maybe you can use KGPE, KGPE, maybe that one is what we 13:27.600 --> 13:34.000 testing running some test against right now. And similar question for UFI is there and isn't in 13:34.000 --> 13:42.960 a state that I could drop some hotness and try with UFI to try to get there on the internet or 13:44.960 --> 13:53.600 I think so maybe not so the question was if if the UFI is in the same state as the Gasey 13:53.600 --> 13:59.680 so we can just grab some photos and test that. The answer is I think so but maybe not all of that is 14:00.800 --> 14:04.320 up to date in this method trend boot stuff which points to the specific 14:05.600 --> 14:12.800 revisions of each component. So my definitely that would be like a part of this in progress 14:14.880 --> 14:20.800 my stone which will be have like a block percent snapshot of what's definitely working but 14:21.760 --> 14:28.000 I'm pretty sure that at this point we could already discuss and help you with testing something 14:28.000 --> 14:42.960 out in UFI as well. I think both definitely definitely Zana is the one we've been working on 14:42.960 --> 15:02.720 lately. In booting there TM stuff on Intel platforms and on IMD both so as magic I suppose magic 15:02.720 --> 15:10.000 when we were talking about AMD implementation for UFI to send us directly but UFI for UFI sorry 15:10.800 --> 15:19.280 DRTM for UFI platforms and Intel should work because we are using it internally if if you have any problems 15:19.280 --> 15:27.280 drop us a line and we'll help you solve them. Yes yes yes yes yes we don't use as an O we use Linux 15:27.280 --> 15:36.000 we don't work with we've done. I know and you will have more problems with then only DRTM 15:36.960 --> 15:59.600 and the other questions. Okay the question was what the state for OptiPlex? I think we've tested 16:00.160 --> 16:08.880 one of the phases on OptiPlex we've seen by us so yeah it should be possible to replicate that yes. 16:08.880 --> 16:23.120 Another question is at all KX like are you planning to import grab like that code to KX? 16:24.400 --> 16:30.640 The question is if we are planning to import grab like that code to KX, I'm not aware of the 16:30.880 --> 16:38.240 plans. I'm not sure I understand the question. Are you asking about supporting KX from the 16:38.240 --> 16:57.920 grab? I think it's really exciting. So let's say okay yes we were discussing this internal in 16:57.920 --> 17:10.000 the Oracle and we have idea we're doing this with grab as intermediary state. So it was discussed 17:10.000 --> 17:17.760 because but there is no code there are some ideas but as I said currently we are focusing mostly on 17:17.760 --> 17:23.920 putting directly from the hardware not switching once again through KX to to to to to to. 17:23.920 --> 17:32.160 So you're meant to pay X from the window to the grab yes because we will be this is quite crazy idea