Thank you guys.
My name is Daniel Kippur.
I work for RACL.
I'm software developer and grabs upstream my tenure since 2005.
I think it doesn't work.
My only issue is only for recording.
I have to speak louder.
Please remind me about that.
Thank you.
I want to present what is happening in the project right now, where we are and other things.
The plan for this presentation, I want to discuss what happened during the last two years.
I want to dive a bit to the cover it to work, which he did during the last three years.
Also, I will be discussing what is happening in the project right now.
And also, I will show you some statistics for federal grabs upstream patches.
So, let's start from the beginning, let's say.
I suppose that it is not needed to remind what is grab is.
In general, it is a bootloader, but we are not focusing on UFI income horizon to system D.
We support all architectures and platforms, which are most of our architectures and platforms.
I suppose there are some platforms which don't support architectures.
But there are tons of architectures and platforms, and we try to give a user a lot of flexibility, what can be done, etc.
So, the grapple is happened in the last December, and we provided support for new compilers, new bidinutils tools, and other stuff.
We also finally did a unification on the UFI Linux kernel loader.
Before that, every architectures had own implementation of EFI kernel loader.
And additionally, to make the problem much more complicated, we had a completely different X86 architecture loader.
This was terrible, and finally, thanks to many people, we were able to merge all these EFI bootloaders into one thing,
which is common across all architectures.
There are some minor differences which we had to leave, but unfortunately, they are minor,
and I suppose that at some point we will remove them completely.
We also, as I thought earlier during the Linux presentation, added initial support for bootloader interface,
and I suppose that we will be implementing more specifications which were developed by SystemD guys.
We also, during last development efforts, made some important changes to the Grapp runtime memory management.
Previous implementation was very rigid, and it allocated memory from the firmware just at the initialization of the Grapp.
So, it didn't allow us, for example, to run Ergon 2 KDF.
So, we had to change this memory allocator implementation, and finally, Grapp is able to just allocate the memory from the UFI firmware just on the runtime.
So, it is a very nice thing.
We also added support for PCI and MMI or UARTs, which is, I think, very important if you are some problems,
because you are able to print all debug messages directly to these UARTs.
We added Sdl support, LongArts support, TPM driver fixes.
In previous versions, we had problems with this driver, because when UFI failed, then TPM driver failed, then boot stopped.
So, this was a problem. Currently, this is fixed.
We also added debugging support improvements, improved test cases, improved documentation, and tons of other fixes.
As I said at the beginning, I would like to dive into the coverity work, which we did.
Finally, we were able to achieve our goal.
Currently, we have zero outstanding defects in the coverity, which is, I think, nice.
And this work was initiated by Andrei Bozhankov in 2013.
Later, Vladimir Serbinian, who is also a graph-matterner joint, and together they continued this work until 2017.
We started this work in 2020, when boot-hole security popped up, and it took us years to do analysis of all coverity issues, not solved earlier.
So, finally, we fixed more than 600 issues reported by the coverity.
Sorry, we did analyze more than 600 issues, and fixed more than 500 of them.
About 100 of issues were false positives or something like that.
After that, we ran a new coverity tool, which revealed additional four issues.
Fortunately, they were not grave, and we fixed them quite quickly.
So, all of these issues currently are fixed.
At this point, in general, we do not accept any patches, which introduce coverity issues.
So, this is not accepted at this point.
We also employing fuzzing and other tools to find bugs in the graph code.
And I would like to thank you all these people who are working on the coverity stuff.
At the beginning, it was quite easy, because the reports which we were looking at were quite simple.
But if we were diving deeper and deeper into other issues,
it came out that the coverity reports are very confusing and difficult to fix, or even understand.
So, this took a lot of time to do analysis, especially the final few issues.
One issue which we analyzed with Vadimir was in the Grapp-Moller allocator.
And even if we thought that we fixed the issue, the coverity was thinking that it is not fixed.
We don't understand why, but we finally silenced forcibly coverity, because we were not able,
even we contacted with the coverity company to get information why it works in that way.
And we were not able to understand how this works.
But as I said, in general, currently we have coverity issues reduced to zero,
and we will not accept any patches which will introduce any coverity issues.
So, what is happening right now in the Grapp project?
As you may know, currently Microsoft requires that PE binaries has to have special properties.
So, first of all, it is required that PE files must be aligned at the page size.
And the more important thing is that you cannot combine a right attribute with executor output for the data section.
So, it means we have a special code which properly aligns of this section of the shim,
of the Grapp-Loder, of the kernel, and it requires a lot of work.
Shim currently has support for an X.
Currently we are working on support for an X.
It was initially done by Red Hat.
Currently work is taken over by Oracle and we are currently looking at this code.
And I hope that shortly we will be able to post updated code for the upstream version on the Grapp mailing list.
And I hope that it will be matched in the upcoming release.
We are also working quite closely with the Tenchbot project.
I do not want to dive in this topic because we have presentation at the end of this dev room.
It will be made by Jack and Maci from 3MDep.
So, they will provide more information about the Tenchbot project.
Unfortunately, we have to update all embedded Lips.
The most difficult problem at this point is the Jypri-Library which provides encryption primitives for the Grapp.
Currently we are discussing various options.
Also, we are considering moving from the Jypri-Lib-Jypri which is a huge thing.
Thank you.
And maybe not completely aligned with current Grapp needs.
So, one guy with whom I am discussing the Grapp dev app,
proposed that maybe we will move to something which is a simple library which is just to file a forget its name.
It is on mailing list if you are interested in, which contains just two files.
One C file which implements the cryptoprimitives and one header file.
So, it will much, much more simplify the abandon this into the Grapp.
And this way we will get Argon to KDF which allows us another thing in the Grapp
which is automatic disk unlock with TPM2.
The another issue which we have is that due to Horiex historic reasons we have distributions carrying tone of downstream patches.
And this make Grapp upstream code more difficult to use in these distributions.
I will discuss this later and I will show you some numbers to give you a clue what the size of problem is.
We are also working on fix ups and clean ups for documentation.
We are also looking for setting up CI infrastructure at this point.
In general, I do all tests manually so this is not very convenient and I think that it shouldn't work in that way for projects like Grapp.
We expect that the next code free will be around October 2024 and next Grapp will be close to November 2242.
So, as I said, let's have a look at Fedora downstream Grapp patches.
This is Rafa estimates.
These statistics were prepared by Alec Brown, my colleague from Oracle.
So, you have to take this number with grain of salt because we were just looking for at the names of the patches.
So, if the names of the patches in the upstream were a bit different, for example, by dot or something like that, then we were not able to identify them.
But this shows you that we have huge problems with the downstream patches and this is due to historic reasons.
In general, at this point, we want to focus also on merging most of these downstream patches.
I will show you more numbers which are more relevant, I think.
Sorry, not this one.
As you can see, Fedora 40 currently carries around more than 350 patches.
Of course, there are some of them which were back ported to this release, but still we have more than 200 downstream patches, which, let's say, makes Grapp downstream maintenance very difficult
and also provides some problems for Grapp upstream development.
For example, some people come to us and ask about things which are specific to a given distro, but do not apply to Grapp upstream.
So, this is a real problem.
In general, we try to focus on this work in the following months.
Alec Brown would be helping with this, but we are looking for more people who want to review these patches, who want to work on these patches.
If you know a given area, you have experienced a given area and you are happy to help with that, that will be perfect.
So, I think that's it from my side.
Do you have any questions?
Yes.
Thank you.
Go ahead.
Thank you for the talk.
Are there any plans to modernize the Multi-Boot 2 specification?
Right now, most of the definitions there are only x86 and MIPS and are constrained to 32 bits, so you can't have modules above 4 gigabytes, you can't have entry points above 4 gigabytes.
Which fields are there?
How to date it?
A bit.
What is the process for getting the fixed?
I'm not sure what is the idea behind using this protocol, but I'm not against using this protocol, but I would want to understand use cases, etc.
If you want to improve this spec, just take the latest spec from the grab source code and work on it.
I'm happy to review it, to discuss other things and solutions.
I think that, especially on EFI world, currently we are deprecated using this kind of protocols.
For example, we deprecated usage in the kernel, deprecated usage of Handover protocol, which was also artificially designed for EFI environment many, many, many years ago.
I think that similar case is with Maltiboot 2, Maltiboot in general.
And I think that on EFI platforms we should use EFI interfaces, as for example I suggested, but on non-EFI platform I think that it makes sense to consider something like Maltiboot 2.
Of course, if it is properly improved, I think its design is quite generic and can allow us to use it on different architectures and platforms.
But I think that we should not target this protocol to EFI environments, I think.
This is my opinion.
Does it reply your question?
I can just send you some pictures for example for ARC.
Oh sure, I'm happy to review them and discuss on my weakness.
Go ahead.
I'm a gen2 developer here and one of the biggest pain points historically was that your release case, you mentioned that the next release was Manfrouk Tova,
which I hope that will actually ship them because historically some of these released it, it had to wait 2-3 years.
Same problems with the work here, all these patches, and they give you simple patches.
I think for the community and for downstreams, just getting more updates on how frequently you feel like is one of the biggest.
So, the suggestion from the audience is that we should show them the cadence of the releases and speed up the review process.
I completely agree.
That is, as you saw, we are aiming at making a release at the end of this year, but my goal is that and from the talks with other folks,
my goal is to make a release cadence around twice per year.
This is my goal.
But due to lack of resources, at this point it is quite difficult.
So, we are looking for more help from the community in reviewing patches.
Especially, I think that at this point one of the most important projects is forward-porting patches from the downstream as much as possible
to reduce this backlog.
And I think that it will help to review currently posted patches on the mailing list, etc.
I hope that this surprised your questions.
Thank you. Any questions? Go ahead.
Yeah, yeah, I'm looking for you.
From the stats that you showed with all the patches and all the releases, do you have any estimate on how much are bug fixes and how much are the file systems and how much is integration?
The question is how the audience is referring to the list of the patches which are in downstream.
And the question is how many of these patches are bug fixes for the sheen, for the EFI protocol and other stuff.
As I said, this is only a rough estimate.
We just did this work a few days ago, so we don't have these numbers.
Alex started looking.
After some discussion, we decided that we will be looking mostly at this point, mostly at the UFI code to identify which EFI code is.
It doesn't need it, which code should be fixed and matched, etc.
So if you need more information, if I have one, I can share with you.
Thank you. Go ahead.
A question about your statistic in the slide before that.
Stefan?
How does that add up to 222, 323? What's the total? What's missing?
Could you repeat once again?
If you take any line and write up the numbers, it doesn't come up to 460.
22 patches?
What's the total?
It's the total patches were put on the given upstream version.
So for example, let's go back to this one.
The first number shows you how many matches were put on the graph 2.0 upstream.
87 patches were backported.
It means that if some patches were put into the master, into the graph 3, then Fedora started getting some patches from the upstream.
So 87 means that these patches come from master graph.
64 new patches.
It means that there are new patches which didn't come into upstream and just live only in downstream Fedora.
And as you can see, the number of patches is increasing.
So this is a bit confusing.
As I said, we were working during the last few days to just show you numbers.
So there are no precise, we have to take them with grain or salt.
Just wanted to show you the size of problems which we have at this point.
One of these patches is bootloader spec support. Is there someone working on getting the upstream?
Not yet, but if anybody wants to work...
Oh, okay.
The question is if somebody is looking at boot a spec support which is currently downstream and wants to upstream this code.
Not yet. I haven't heard about this work, but if somebody wants to pick up this work, I will be happy to review this on my main list.
So there are all things which are defined.
Various boot protocols I think that can be implemented in the graph.
And we are happy to review those.
Does it apply because? Okay. Go ahead.
So for the patches, a lot of Fedora patches are actually new features.
Yeah, yeah, yeah.
My question is about multi-boot support.
Okay.
So if multi-boot support is getting deprecated, what's the recommended way for booting Zen?
Yes. The question is about multi-boot protocol and if the plans are to deprecate this protocol, how we boot the Zen?
Which relies on this boot protocol? Yes.
We should move to, in general, EFI protocols which are currently used and situation gets much worse there because there are some discussions about dropping support for Shimlog protocol because it makes some problems in some situations.
In general, we will be moving from various kinds of strange of bootloaders on EFI platform to just start load image and start image protocol functions and they should be used.
I communicated this to Zen community.
They are aware of that.
They were not happy with that but they told me that it is better that I told them about this problem now than later because they were considering working more on this multi-boot protocol to support Secuboot.
Does it apply your question? Kind of.
Okay. We can discuss this later as you wish.
Okay. Next question.
Is there a way that we can avoid using grub scripts and have more of the information that Hunter and Debian don't need to create these scripts?
Could you speak louder because I have difficulties with hearing you.
Is there a way for distributions to avoid needing to write grub scripts?
Well, I think that we should repeat the question.
So the question is it is possible to avoid the grub scripts in the distributions to make grub work.
As I understand the question, I think that we should migrate to something different than grub scripts like a mechanism which are used in system D or something like that.
But load aspect, exactly.
So this is a potential way to use these scripts in the grub right now.
So we are considering this.
You heard the discussion on how that somebody will pick up this work and we will be able to match this support shortly in the grub.
Okay. I think that was the last question.
Thank you very much.
Thank you.