Okay. Let's start. My name is Daniel Kiepper. I work for Oracle and I am a grab up stream
my tenor and today I want to present projects that was update as I do it early at this
conference. So I want to discuss a free topic, small or less at the beginning. I would like
to discuss what happened during last year in the project and also later I will discuss
what is happening right now and also I want to show some statistics and some numbers about the
patches, comparison between what is happening in the grab up stream and also what was happening
in the grab for the entire will comment this. So what happened during last year? So we introduced
a few new features, first feature which went into the grab after 2.12 to release it was your
FS support. We also introduced a mechanism to disable command line interface and menu editing
from the grab when you want to disallow users to make some modifications to the grab
CFG or something like that. This is done when you generate the grab image and if you enable
disabled, if you turn on the disabled CLI flag, you generate the image then you will not be able
to do anything. Even the rescue menu is disabled in this situation. So user is not able to do anything
with the CFG or a command line of the URLs. Another very important feature is CoreNX support
which went into the FI platforms. Probably you know that currently Microsoft and FOSS and next let's
say on new binaries which will be signed by them. So it means that in general the P binaries has to
specify special flags that say that binary understands how to say how the code and the data is split
and how it should be mapped in memory and then during the load the firmware marks the data as a
next and of course code is not a right table. So at this point most binaries which are signed by
Microsoft has to have to disproperties. The initial thing which had this property was the
shame because it is the first thing which is run by firmware but we are also forced to introduce this
thing in the in the grab. What it means that CoreNX support is in the grab. It means that first of
all the all the code which is loaded and executed I mean modules into the grab is properly
mapped in memory. So code is not a right table and data of course the data pages are marked
as a non-existable. At this point there is no mechanism currently in the grab which
does this for the kernel images. I will discuss this later because the rest of this thing will be
is currently under development. Also we got as bad support for ELF files and this is a mechanism
as you might know this is a revocation mechanism which is an improvement for for year five revocations
in the kernel. It gives us less flexibility and also it is much better than DBX which requires
more and more memory in EFI to work. So this solves the problem with memory constraints in EFI.
Also we finally got automatic disk unlock with TPM to only EFI and the PIP platforms. So we are
able to use SRTM to decrypt the boot partition and boot and the system directed from the grab.
We improved the detection of phones during configuring. We are also able to load TTF phones and
or TF phones currently during the bike process. Still working on the forvac porting
patches to upstream. We get more people working on this thing. So it is quite
think which is happening right now. Of course we are doing fixes, cleanups and the
documentation updates because we understand that it is important and some things are not clear
in current documentation and so we think that it should be important. And this point if new
feature is introduced I am as a my turn if something is quite complicated to guys.
Explanation, documentation and ask developer to do that. Also we are writing new tests for various
components for example automatic disk unlock with TPM support also went into the
brush together with with some recurrent tests. Now and of course we introduced many
many fixes and cleanups to the project. So what is happening correct now? As I said we
earlier we introduced the core and export to the grab. Right now we are working on the
side of things. But this thing will be implemented in the shims. So shim will provide a special
loader protocol which will replace loadings and start image functions from the EFI firmware
and will provide all mechanics to first of all load the kernel and also properly map the pages
for the code and for the later. So we will rely on the shim to provide this mechanic,
this mechanic to the grab. I know that if I'm not mistaken there is an implementation
in Ubuntu which allows you to do that using only the grab but it requires a separate code
in the grab and we think that it is not a raw, it is not a raw of the grab to do it. Additionally
this loader protocol will provide on the secure boot platforms with secure boot and I
will verify for the kernel images. So this functionality will be provided by the shim itself.
Terence boot support feed for Intel AMD X86 architecture. Currently it is under development.
I will have a presentation in half an hour about that together with my colleague about this so
I don't want to dive deeper into this. Also we are working on BLS and UKI support for the grab.
This support will be based on the fedora patches. We took fedora patches and we based on
all developments on this. Also my colleague is currently updating the UKI support to this.
We have discussed this internally and expect the patches in the following weeks appearing on the
grab development mining. Also in the queue is waiting for a view up and that signature
secure boot support for power PC. We are also together with loading and discussing or discussing
working on the, including the e-grip, including new e-grip in the grab. Unfortunately this is quite
complicated because current version in the grab is very, very old. So having quite long,
but unfortunately, over busy with other stuff. I hope that this year will happen because
I think that we are quite far with this. And the next code freeze and the grappling is planned
in the following maps. So let's move on to this stuff. As you might know,
unfortunately the grab due to its history has a lot of downstream patches. The first number
shows you how many custom patches are currently in a given fedora list in comparison to the
abstinently abstinently. The second number shows you how minted new patches will backporked
from the grab abstinently project. And the third number shows you how many new patches were
introduced into the downstream which are custom and currently not in the, in the, in the, in the
abstinently. And the last number shows you a total number of custom patches which are introduced
over the years. So as you can see situation is quite difficult, but when you look at the grab
to point of six, you can see that situation currently is improving because the third column shows
you that the number of new patches, custom patches which goes into the downstream are going to zero.
This is how it go. And I think that this work is in, is going in good direction. One thing which
currently we agreed with between abstin and downstream project is that new implementation of the
loader protocol and in general mechanism which loads the kernel and executed the kernel from
from the grab which currently is something we will be taken by, by the downstream project. So at
this point we will not have various different kinds of Linux loaders in different,
different downstream projects and also absent. So here the number of custom patches will be,
I think, strongly reduced, but also we are working on reducing number of custom patches in
other areas. So I think that's it for my side. Do you have any questions before
that's the grab project? Yeah. Yes, the question is how the numbers in this slide work?
So the number of patches which are, the first column shows the number of patches which currently
in a given release in comparison to the upstream, but the number of new patches is the number of
new patches which were introduced between, for example, let's see Fedora 39 and 40. So in comparison
to Fedora 39 and 40 we introduced zero new custom patches. For example, in comparison for Fedora
38, between 30 and 39 we introduced just one on one new patch. This is reference to the previous
release of the Fedora. Excuse me? This one shows how many patches were backported from, for example,
Fedora taken a 2.6 at Fedora 34, but also the development of upstream was going forward.
And sometimes folks from Fedora think that some features fixes should be introduced from the
upstream project to the, to the, to the point of six release in the downstream. So there are
things backporting some of the patches from the upstream project. Yes, exactly. That's exactly
the disposal, reducing the number of patches to backport by providing some points for the
release. And Fedora is providing one release. The problem is, yes, I know, we are, we will ask
it for this many times, but due to a lack of necessity, it is very, very difficult. At this point,
we also have problems with releasing minor releases. So at this point, we are not able to focus
on maintaining, for example, to point of six and adding backporting patches to the, to the
obscene. I know this is painful, but certainly we will be working on solving, solving that as soon
as possible. Okay, you were first, I think.
This is, the new part, the question is about the third column, new patches. So new part means
that it is made by downstream project, not provided to the, to the upstream, or it will be later provided.
I assume that the last row of the patch, the first thing we will, we have this patch is about
upstream, so obviously that we cannot keep that open for some kind. So why this?
And so if I understand the question, so you are asking to speed up the process of
moving the patches from the downstream project to the upstream, as soon as possible. I think that
it happens at this point more often. So there is an improvement here, and as you can see the number
of new patches, I mean new patches developed by the downstream project, and to which we are not
provided to upstream. So it is improving. Right now, in general, as I can see, projects is introduced
some patches, especially simple patches, almost immediately provided this patch to the upstream,
and to we try to take this patch as soon as possible. Okay, so.
To be honest, I do not work. The question is, what can be tested even in VM, or what kind of features
cannot be tested through VM, right? So to be honest, I do not work very closely with the test
infrastructure, so I am not able to, let's say, I think what do you could say, something more about that.
Thank you very much. Thank you. Thank you.
Thank you. Thank you. Thank you.
In general, as this is letting me say, we try to test as much as possible in, we fail to
VM, but there are some features, which should be tested in the VM. In general, this infrastructure
improved a lot by Glenn Wasborne, I have recently, often not mistaken, so it is much better than
it was earlier, right now. And more test can be run, or without VM.
Okay, what we, one minute left, so one last question. Okay, go ahead.
So the objective is, if you already have already seen that.
Vladimir posted a patch.
But in general, it is for the system, which is not a provider, let's say, a
few more hopes to load the binary, load the files directly from the file system.
Do you have a use case for this? Yes. Oh, really?
Oh, really? Okay, what is it mapped as an VME staff or something like that?
Okay, okay. Okay, okay.