WEBVTT 00:00.000 --> 00:15.680 Okay. Let's start. My name is Daniel Kiepper. I work for Oracle and I am a grab up stream 00:15.680 --> 00:22.800 my tenor and today I want to present projects that was update as I do it early at this 00:22.800 --> 00:28.960 conference. So I want to discuss a free topic, small or less at the beginning. I would like 00:28.960 --> 00:34.080 to discuss what happened during last year in the project and also later I will discuss 00:34.080 --> 00:43.200 what is happening right now and also I want to show some statistics and some numbers about the 00:43.200 --> 00:50.960 patches, comparison between what is happening in the grab up stream and also what was happening 00:50.960 --> 00:59.680 in the grab for the entire will comment this. So what happened during last year? So we introduced 00:59.680 --> 01:09.520 a few new features, first feature which went into the grab after 2.12 to release it was your 01:09.520 --> 01:18.960 FS support. We also introduced a mechanism to disable command line interface and menu editing 01:18.960 --> 01:28.400 from the grab when you want to disallow users to make some modifications to the grab 01:28.400 --> 01:37.760 CFG or something like that. This is done when you generate the grab image and if you enable 01:37.840 --> 01:49.200 disabled, if you turn on the disabled CLI flag, you generate the image then you will not be able 01:49.200 --> 01:58.320 to do anything. Even the rescue menu is disabled in this situation. So user is not able to do anything 01:58.400 --> 02:08.560 with the CFG or a command line of the URLs. Another very important feature is CoreNX support 02:08.560 --> 02:17.280 which went into the FI platforms. Probably you know that currently Microsoft and FOSS and next let's 02:18.080 --> 02:30.160 say on new binaries which will be signed by them. So it means that in general the P binaries has to 02:30.160 --> 02:42.640 specify special flags that say that binary understands how to say how the code and the data is split 02:42.640 --> 02:50.400 and how it should be mapped in memory and then during the load the firmware marks the data as a 02:50.400 --> 02:58.880 next and of course code is not a right table. So at this point most binaries which are signed by 02:58.880 --> 03:08.000 Microsoft has to have to disproperties. The initial thing which had this property was the 03:08.000 --> 03:15.280 shame because it is the first thing which is run by firmware but we are also forced to introduce this 03:15.360 --> 03:24.480 thing in the in the grab. What it means that CoreNX support is in the grab. It means that first of 03:24.480 --> 03:31.840 all the all the code which is loaded and executed I mean modules into the grab is properly 03:31.840 --> 03:40.000 mapped in memory. So code is not a right table and data of course the data pages are marked 03:40.080 --> 03:48.480 as a non-existable. At this point there is no mechanism currently in the grab which 03:51.040 --> 04:01.600 does this for the kernel images. I will discuss this later because the rest of this thing will be 04:02.320 --> 04:12.080 is currently under development. Also we got as bad support for ELF files and this is a mechanism 04:12.080 --> 04:20.000 as you might know this is a revocation mechanism which is an improvement for for year five revocations 04:20.000 --> 04:32.800 in the kernel. It gives us less flexibility and also it is much better than DBX which requires 04:32.800 --> 04:45.520 more and more memory in EFI to work. So this solves the problem with memory constraints in EFI. 04:46.480 --> 04:56.000 Also we finally got automatic disk unlock with TPM to only EFI and the PIP platforms. So we are 04:56.000 --> 05:06.320 able to use SRTM to decrypt the boot partition and boot and the system directed from the grab. 05:06.720 --> 05:16.320 We improved the detection of phones during configuring. We are also able to load TTF phones and 05:16.320 --> 05:23.920 or TF phones currently during the bike process. Still working on the forvac porting 05:24.880 --> 05:36.880 patches to upstream. We get more people working on this thing. So it is quite 05:38.720 --> 05:43.200 think which is happening right now. Of course we are doing fixes, cleanups and the 05:43.200 --> 05:51.200 documentation updates because we understand that it is important and some things are not clear 05:51.280 --> 05:57.760 in current documentation and so we think that it should be important. And this point if new 05:57.760 --> 06:04.640 feature is introduced I am as a my turn if something is quite complicated to guys. 06:06.000 --> 06:14.400 Explanation, documentation and ask developer to do that. Also we are writing new tests for various 06:14.400 --> 06:20.640 components for example automatic disk unlock with TPM support also went into the 06:20.800 --> 06:27.120 brush together with with some recurrent tests. Now and of course we introduced many 06:27.120 --> 06:34.400 many fixes and cleanups to the project. So what is happening correct now? As I said we 06:34.400 --> 06:41.440 earlier we introduced the core and export to the grab. Right now we are working on the 06:41.440 --> 06:55.120 side of things. But this thing will be implemented in the shims. So shim will provide a special 06:55.120 --> 07:03.360 loader protocol which will replace loadings and start image functions from the EFI firmware 07:03.360 --> 07:11.200 and will provide all mechanics to first of all load the kernel and also properly map the pages 07:11.200 --> 07:20.640 for the code and for the later. So we will rely on the shim to provide this mechanic, 07:20.640 --> 07:26.720 this mechanic to the grab. I know that if I'm not mistaken there is an implementation 07:28.240 --> 07:36.480 in Ubuntu which allows you to do that using only the grab but it requires a separate code 07:36.560 --> 07:46.400 in the grab and we think that it is not a raw, it is not a raw of the grab to do it. Additionally 07:47.200 --> 07:52.320 this loader protocol will provide on the secure boot platforms with secure boot and I 07:52.320 --> 08:02.640 will verify for the kernel images. So this functionality will be provided by the shim itself. 08:03.200 --> 08:13.920 Terence boot support feed for Intel AMD X86 architecture. Currently it is under development. 08:13.920 --> 08:20.320 I will have a presentation in half an hour about that together with my colleague about this so 08:20.320 --> 08:28.560 I don't want to dive deeper into this. Also we are working on BLS and UKI support for the grab. 08:29.520 --> 08:36.240 This support will be based on the fedora patches. We took fedora patches and we based on 08:38.160 --> 08:44.480 all developments on this. Also my colleague is currently updating the UKI support to this. 08:44.480 --> 08:51.280 We have discussed this internally and expect the patches in the following weeks appearing on the 08:51.280 --> 08:58.320 grab development mining. Also in the queue is waiting for a view up and that signature 08:58.320 --> 09:06.240 secure boot support for power PC. We are also together with loading and discussing or discussing 09:06.240 --> 09:17.360 working on the, including the e-grip, including new e-grip in the grab. Unfortunately this is quite 09:17.360 --> 09:22.880 complicated because current version in the grab is very, very old. So having quite long, 09:22.880 --> 09:31.120 but unfortunately, over busy with other stuff. I hope that this year will happen because 09:31.120 --> 09:37.840 I think that we are quite far with this. And the next code freeze and the grappling is planned 09:38.400 --> 09:46.560 in the following maps. So let's move on to this stuff. As you might know, 09:46.560 --> 09:54.160 unfortunately the grab due to its history has a lot of downstream patches. The first number 09:54.160 --> 10:06.160 shows you how many custom patches are currently in a given fedora list in comparison to the 10:06.160 --> 10:13.440 abstinently abstinently. The second number shows you how minted new patches will backporked 10:13.600 --> 10:19.360 from the grab abstinently project. And the third number shows you how many new patches were 10:19.360 --> 10:29.760 introduced into the downstream which are custom and currently not in the, in the, in the, in the 10:29.760 --> 10:36.880 abstinently. And the last number shows you a total number of custom patches which are introduced 10:36.960 --> 10:44.880 over the years. So as you can see situation is quite difficult, but when you look at the grab 10:44.880 --> 10:52.160 to point of six, you can see that situation currently is improving because the third column shows 10:52.160 --> 11:00.800 you that the number of new patches, custom patches which goes into the downstream are going to zero. 11:00.800 --> 11:13.760 This is how it go. And I think that this work is in, is going in good direction. One thing which 11:13.760 --> 11:22.320 currently we agreed with between abstin and downstream project is that new implementation of the 11:22.560 --> 11:33.280 loader protocol and in general mechanism which loads the kernel and executed the kernel from 11:33.280 --> 11:42.480 from the grab which currently is something we will be taken by, by the downstream project. So at 11:42.480 --> 11:49.280 this point we will not have various different kinds of Linux loaders in different, 11:49.360 --> 11:59.520 different downstream projects and also absent. So here the number of custom patches will be, 11:59.520 --> 12:06.880 I think, strongly reduced, but also we are working on reducing number of custom patches in 12:06.880 --> 12:15.040 other areas. So I think that's it for my side. Do you have any questions before 12:15.280 --> 12:44.560 that's the grab project? Yeah. Yes, the question is how the numbers in this slide work? 12:44.560 --> 12:54.720 So the number of patches which are, the first column shows the number of patches which currently 12:54.720 --> 13:03.760 in a given release in comparison to the upstream, but the number of new patches is the number of 13:03.760 --> 13:13.680 new patches which were introduced between, for example, let's see Fedora 39 and 40. So in comparison 13:13.840 --> 13:22.720 to Fedora 39 and 40 we introduced zero new custom patches. For example, in comparison for Fedora 13:22.720 --> 13:33.120 38, between 30 and 39 we introduced just one on one new patch. This is reference to the previous 13:33.200 --> 13:46.720 release of the Fedora. Excuse me? This one shows how many patches were backported from, for example, 13:48.720 --> 13:56.720 Fedora taken a 2.6 at Fedora 34, but also the development of upstream was going forward. 13:57.600 --> 14:05.840 And sometimes folks from Fedora think that some features fixes should be introduced from the 14:05.840 --> 14:11.840 upstream project to the, to the, to the point of six release in the downstream. So there are 14:11.840 --> 14:24.320 things backporting some of the patches from the upstream project. Yes, exactly. That's exactly 14:26.720 --> 14:32.720 the disposal, reducing the number of patches to backport by providing some points for the 14:32.720 --> 14:41.760 release. And Fedora is providing one release. The problem is, yes, I know, we are, we will ask 14:41.760 --> 14:48.800 it for this many times, but due to a lack of necessity, it is very, very difficult. At this point, 14:48.800 --> 14:55.840 we also have problems with releasing minor releases. So at this point, we are not able to focus 14:55.920 --> 15:01.920 on maintaining, for example, to point of six and adding backporting patches to the, to the 15:01.920 --> 15:09.360 obscene. I know this is painful, but certainly we will be working on solving, solving that as soon 15:09.360 --> 15:12.560 as possible. Okay, you were first, I think. 15:26.000 --> 15:37.280 This is, the new part, the question is about the third column, new patches. So new part means 15:37.280 --> 15:44.960 that it is made by downstream project, not provided to the, to the upstream, or it will be later provided. 15:56.080 --> 16:00.720 I assume that the last row of the patch, the first thing we will, we have this patch is about 16:00.720 --> 16:05.120 upstream, so obviously that we cannot keep that open for some kind. So why this? 16:06.320 --> 16:13.200 And so if I understand the question, so you are asking to speed up the process of 16:14.000 --> 16:20.080 moving the patches from the downstream project to the upstream, as soon as possible. I think that 16:20.080 --> 16:27.360 it happens at this point more often. So there is an improvement here, and as you can see the number 16:27.360 --> 16:33.600 of new patches, I mean new patches developed by the downstream project, and to which we are not 16:33.600 --> 16:42.000 provided to upstream. So it is improving. Right now, in general, as I can see, projects is introduced 16:42.000 --> 16:47.520 some patches, especially simple patches, almost immediately provided this patch to the upstream, 16:47.520 --> 16:52.080 and to we try to take this patch as soon as possible. Okay, so. 17:05.920 --> 17:12.640 To be honest, I do not work. The question is, what can be tested even in VM, or what kind of features 17:12.640 --> 17:18.960 cannot be tested through VM, right? So to be honest, I do not work very closely with the test 17:18.960 --> 17:26.320 infrastructure, so I am not able to, let's say, I think what do you could say, something more about that. 17:42.640 --> 17:46.720 Thank you very much. Thank you. Thank you. 17:46.720 --> 17:50.720 Thank you. Thank you. Thank you. 18:00.560 --> 18:10.800 In general, as this is letting me say, we try to test as much as possible in, we fail to 18:10.800 --> 18:16.880 VM, but there are some features, which should be tested in the VM. In general, this infrastructure 18:16.880 --> 18:24.800 improved a lot by Glenn Wasborne, I have recently, often not mistaken, so it is much better than 18:24.800 --> 18:33.600 it was earlier, right now. And more test can be run, or without VM. 18:41.440 --> 18:51.280 Okay, what we, one minute left, so one last question. Okay, go ahead. 18:51.280 --> 18:59.600 So the objective is, if you already have already seen that. 19:01.440 --> 19:02.880 Vladimir posted a patch. 19:10.400 --> 19:16.480 But in general, it is for the system, which is not a provider, let's say, a 19:16.480 --> 19:22.480 few more hopes to load the binary, load the files directly from the file system. 19:22.480 --> 19:25.520 Do you have a use case for this? Yes. Oh, really? 19:37.360 --> 19:43.760 Oh, really? Okay, what is it mapped as an VME staff or something like that? 19:46.480 --> 19:51.840 Okay, okay. Okay, okay.