Hi, I'm Leonard Patering, and today I'm coming for your bootloader. Yeah, this is not as new as the stuff that I talked about yesterday,

but I still think it's kind of interesting, but of course I would say that. But anyway, I'm going to talk about two closely related but distinct topics. Like one is the bootloader spec and one is SDBoot. SDBoot, some of you might already know, but my hope is to make it more well known among those who don't know it yet.

So, yeah, I'm talking about bootloaders. So let's jump right in. What is the bootloader specification? What's the first topic I want to talk about? The bootloader specification is a specification which you find under this URL. It defines, well, let's then ask the next question, what is actually SDBoot?

What's the other topic? That is a bootloader that is documented there, and it used to be called gummy-boot, and it implements the bootloader specification. So let's have a closer look at what bootloader specification actually is.

It's a generic specification on any platform, any firmware, that allows you to define boot entries, which are simple drop-in files. These drop-in files are supposed to be placed below a location called $boot. Like that's just a wildcard name because there might be various different ways to reference it.

So it's not really in anything called $boot, that's just like in a variable. Where one option is that $boot is a partition of type EA hex on MBR partition tables, or on a partition of this UUID type on GPT.

Like we just picked that up because it was not used yet. Option B is that $boot actually equals the EFI system partition. For those who don't know EFI that well, I mean all your laptops, all your current laptops at least probably boot with EFI these days, and the way how Linux gets ultimately started is that the firmware,

the EFI firmware, finds a special partition, which is the ESP, on your hard disk, and when it finds it, it basically starts some binary in that thing that is traditionally grub, but I kind of want to advertise it to you to make this SD boot instead,

and that then eventually invokes the Linux kernel, and then from there on you get inner-dine and system using control. But yeah, EFI system partition is something you have on all your computers, regardless if you run Windows or Linux or even Mac OS,

they all have one ESP that contains the stuff that the firmware is supposed to load. The specification that I'm talking about can use the ESP to find these snippets that I'm talking about. The file system for $boot is supposed to be VFAD, like Microsoft file system.

The ESP kind of suggests that anyway if it's used like that, but even if you're not using the ESP for this purpose, use VFAD anyway, but this is not actually enforced or required or anything like this. This is just a suggestion. So these snippets each define a boot menu item. You know grub when it shows you this menu that you select what you actually want to boot?

Each of these snippets actually defines one of those. Just as a side note, by the way, if you actually use the GPT partition with that UUID value or with that MBR marker, then System.ly actually mounts this automatically at slash boot,

which is something really, really nice because it makes things very robust and you don't have to have at CFS type of route. Any partition that is marked that way that is on the same hard disk as the root partition of your operating system will be entirely automatically always be mounted to slash boot unless you actually have a manual entry, in which case that takes precedence.

And similar, if you use option B, yeah, the ESP gets mounted to slash EFI nowadays unless you have a manual entry for it again. So this is actually little known, and unfortunately most of the distributions don't actually make use of this. They really, really should because it allows you to basically boot up the system

without any entry at that step. But anyway, this is kind of a sideshow here. Actually it just is supposed to show you that if you stick to the locations for the bootloader spec that I just suggested, then you have this wonderful benefit that after boot everything is automatically discovered for you as well. So let's have a closer look on these drop-ins that I mentioned.

Each drop-in, as mentioned, defines one entry in the bootloader menu. There are two types of these. There's type number one, which is like a config file. These config files just define a kernel, just boot, and then it already boots a title for that, a version for that, and then an entry in the boot menu is created through that.

Yeah, simple text files describing kernel, entity name, and other metadata. And there's type two. It's in a slightly different directory, and these are EFI binaries. For those who don't know ESP that well, ESP, EFI that well, EFI is actually a little bit like this firmware interface. It's a little bit of an operating system of its own

that inherits lots of semantics from DOS, but also from Windows, not so many from Unix, but it knows a concept of EFI binaries, which are just executables, as you might know them. Now, in the second type two mode, the entries are just one EFI binary for each menu entry, right?

And no further data, just that. Let's have a closer look at type one. Type one entries are generic and very flexible because you can create them with a text editor, and then you can just add to that whatever you want to add. You can generate them with a script.

It's completely up to you and very, very simple. Type two, on the other hand, are simple in a different way because basically you just have for each boot menu entry that you have, you have altogether only one file because the EFI file encapsulates all the other bits in one, right? So because it's one file that incorporates the EFI binary

for the operating system, like the Linux kernel, also incorporates some metadata and things like that, you can sign them as one. That is awesome for secure boot stuff. Of course, this concept is specific to EFI, while the bootloader spec is supposed to be generic and useful outside of the EFI spec.

If you use these kinds of binaries, of course, you are strictly within EFI simply because the concept of EFI executables does not exist anywhere else. By the way, if any of you have any questions, I know that this is a lot of very low-level technical stuff. By all means, do interrupt me right away in case I can clarify something.

What's also awesome about type two stuff is because it's a single file, we can do single file updates. This is really nice for something as fragile as a bootloader because it basically means that dropping in a new entry into the boot menu means dropping in one file. Removing one means removing one file.

Renaming something means renaming one file. So you never have this risk that you update, you drop something in there, and you drop something in there, and you drop something at the third place, and then you have to pull it all together by adding this force file. And then if something aborts in the middle, you get a half-installed kernel, and the initrd is missing and stuff like that. All of that doesn't exist because it's just one file.

Both of these types are equally supported by the bootloader specification, and both of the types have their use cases. For many use cases, type two is nicer. For other use cases, type one is nicer. To be more specific how this can look like, this, for example, is the bootloader specification snippet type one for Fedora 30.

I hope you can actually read that, even in the back rows there. It's a very, very simple configuration file. It's purposefully simple so that even people who hack on bootloaders can easily write a parser for this. So there's no JSON, no fancy stuff,

there's no continuation in lines or anything like that. It's just one word followed by some value. I think most of this should be pretty self-explanatory. There's a field title. That's the name for the bootloader menu item. There's the version, which is the version for that. The idea why these entries have versions

is so that the bootloader menu can automatically sort each entry and automatically put the newest entry first. The machine ID is useful. The machine ID is actually the same machine ID that you see in etsy machine ID after you booted up the system. The idea is basically that if you have multiple operating systems, multiple Linuxes installed on the same system,

that you can see which options, which kernels actually belong together simply because they will all carry the same machine ID. There is options. That's really just the kernel command line string. There is Linux. This line actually specifies the kernel binary to execute. And there's initrd, which, you guessed it, specifies the initrd.

I know this is, again, very technical, and maybe some of you don't know what an initrd is. An initrd is basically the first thing that is the Linux kernel initialized. After the kernel itself initialized, it starts the first user-space program. And on most generic Linux distributions, this first program sits in a little bit, something like a tarball,

but it's actually not a tarball, that is loaded into memory by the bootloader already. And that thing is then responsible for finding the rest of the operating system. Usually when you boot a Linux system, you combine both. This is the kernel, and this is the first program you're supposed to start. So that's what it's about.

For anyone who ever dealt with bootloaders, this should be very, very self-explanatory. As mentioned, both types are supposed to be complementary. You can use them together if you want. You can install multiple operating systems on your hard disk,

and they will all share the same ESP or the same $boot location. All these operating systems can drop in their own boot menu items simply by dropping in one or more files, in the case of type 1 or type 2. But each one of them, because they can drop in their own files,

they will not step over the files of the others, which is systematically different from how things used to be with Grub and all these bootloaders, because Grub can only be owned by one operating system at a time, and when you install multiple Linux operating systems on the same system, they end up fighting for who owns the bootloader

and how the other ones get to register themselves. Anyway, in the bootloader spec, all items describe themselves and can be combined freely. This is what I just said. Bootloader and drop-in directories are shared between the OSes.

That's kind of the key here, right? If you ever install multiple operating systems or just multiple versions of the same operating system, like Fedora 30 and Fedora 31, you always have this problem that they fight for who owns the bootloader and who gets to write Grub CFG or whatever it's called.

This is supposed to fix this, right? Simply by taking a lesson from how we do drop-in directories from RPMs. You nowadays know that, for example, you install a GNOME program via an RPM on your system, and what actually happens to make it show up in the menu of GNOME Shell, for example, is they drop in a .desktop file into some directory where GNOME Shell ends up looking.

We just say, and this model is used all across Linux nowadays, like, for example, if you have an RPM that contains a System.ly service, what does it do? It drops in one .service file into a directory in Etsy, and that's how System.ly learns about it. So this is how we do these things in Linux, and the bootloader spec is ultimately just taking that inspiration

and saying drop-in directories are awesome for jointly managed but independent loose coupling components to register something with something else. So let's just do that for the bootloader as well. So bootloader and drop-in directories are shared between OSes in a safe way without these multiple operating systems

to ever step on each other's toes because they will never own the same files together. They will only drop stuff into common directories together. Of course, the bootloader

that actually boots all these operating systems, that needs to be installed once, but the idea is really you have one bootloader and many cooperating players, multiple versions of the same operating system, or multiple operating systems altogether. The bootloader specification, this was a very quick overview of what it does.

If you want to read the full thing, go to the website. It tells you all the further details about this. The takeaway is the bootloader specification is supposed to be a very generic way how operating systems can describe how they want to be started. It's implementable by any bootloader. In fact, I, a couple of years ago, wrote a module for Grub that just implemented that,

the big difference being, in that case, you wouldn't have to constantly write Grub CFG when you add a new kernel, but it would just find automatically what these bootloader specification snippets actually defined. One specific implementation is the second part of the talk that I'm going to want to talk about.

This is SDBoot. It's the EFI bootloader that's shipped along with systemd. You can use it independently too, but it helps us maintaining that together with systemd because it basically allows us to do, adds a couple of integration points between systemd on the host and the bootloader before it. systemd also makes use of the bootloader specification at a different place,

specifically in systemd's kxec reboot mode. You know that if you reboot a systemd system, you do that with system control reboot, but there's also systemd system control kxec. If you do that, then we won't return to the bootloader,

and the bootloader will start the new operating system to start after the reboot, but instead it's the old Linux that finds the new Linux kernel to start and then uses the kernel's kxec mechanism to start that. The kxec is something that the kernel supports where you basically can replace the current kernel with another kernel.

If you use the system control kxec, we somehow need to figure out which kernels to actually start. So we use the bootloader specification with that. So that basically allows you to actually even use systemd itself as a bootloader for another operating system that is registered that way. So far about the bootloader specification.

If anyone has any questions about this so far, it would be the perfect time to ask a question now. What about the support for other operating systems? I mean, in the past you hard-coded Linux, but what about FreeBSD or even, in the good future, Microsoft Windows?

So, very good point. Here you see the fifth line that says Linux. This is how you specify a Linux kernel. Actually, this is just one example. There are a couple of more stances to find. There's one more, for example, it's called EFI.

Then you can specify an EFI binary. In Windows and MacOS, they get started as EFI binary. That's how we can hook those up. There are also people who have sent us a patch and we merged it for multi-boot specification, which is how you can start FreeBSD and these kind of things. Yeah, so the bootloader that we implemented ourselves, like SD-boot, does not implement the multi-boot specification

for the simple reason it's too dumb. But the bootloader specification is really supposed to be something that everybody can implement, right? Bootloaders for MBR, bootloaders for whatever else you want. We're not even just that, actually. Ideally, we want that the bootloader specification is actually something that the firmware has to implement directly

because there's no reason to plug a bootloader between if it doesn't do much more than just show a boot menu. With multiple operating systems operating cooperatively to add entries,

how is the default entry determined? So that's a very good question, but let me quickly finish that, but now I forgot what you... Well, the tape A says Linux. It doesn't do that. Type 1 says nothing Linux-specific. It's type 2 that says this.

Yeah, it has Linux in it, but it doesn't matter, really, what you have there. You can put anything in there. So, I mean, we put the Linux in there because these are EFI binaries where we request that you add a special metadata object into the binary so that we can extract from the binary

the information like what's the name for the menu entry, what's the version for this, so that we can have that information, right? And that is Linux-specific, but also Linux-specific. People could also do that with Linux binaries. Ignore the Linux thing. Anyway, your question again was about... What was it again? Default boot entry.

Oh, the default boot entry. So, SD boot, right? Like, I mean, this is, of course, the precise algorithm implemented for this is up to the bootloader that wants to do this. SD boot has a logic. It orders by the menu entry name alphabetically, and then individually for each of these, it orders by version, putting the newest version first.

So if you only have one operating system installed, it's always going to be the newest one of that, and if you have multiple, then it's beneficial if your operating system starts with an A. Yeah, that's why we did that, of course.

So, what about integration with different architectures, like IRM and so on? So, the specification is explicitly supposed to be entirely generic regarding which kind of firmware you have and what kind of bootloader you have and also what kind of architecture you have.

Our implementation only works for EFI. People are running it on ARM and on x8632 and on AMD64, and I think even some people did it for on AI64. I'm not sure why they care about that stuff, but, I mean, this specification is so generic, right?

There's nothing specific in there. There's actually one key, but I don't have that here, but there's actually one key defined that says architecture even for the snippets, because sometimes it might be interesting that you might want control, that you can define a 32-bit kernel that you want to show on 64-bit EFI

because that's actually compatible some way, or sometimes you don't want that, so we added this key specifically so that you can make filtering there and decide things like this. But, yeah, summary is the specification supports your bootloader, hopefully, too. Anyway, then let's switch to the SD boot.

So SD boot, I always claim it's a bootloader, but it's actually not. It's really just a boot menu. Like, a bootloader is something that takes some operating system image, loads it into memory, and then jumps into it. SD boot doesn't do that. SD boot is an EFI binary, and it renders a nice menu on screen. You can use keyboard and stuff like that.

And what does it do when you select one? It just invokes whatever you selected as an EFI binary again. So it's the BIOS, the firmware, that's actually doing the bootloading. It's not SD boot. Of course, this distinction, who's actually loading stuff into memory and stuff like that, is irrelevant for most people. That's why we just sloppily call it a bootloader,

even if it's really just a dumb, dumb menu. SD boot is EFI only. It makes the world so much easier because we have file system access. We can do all kinds of very simple stuff. SD boot, as mentioned, is shipped with systemd for reasons that we can pass lots of little bits and information

between systemd to the bootloader and from the bootloader to systemd. It starts with performance data, but it's also that systemd can tell SD boot for the next reboot what it shall be booting into, which is pretty cool, actually, because you can then save from, for example, GDM. You can click on something, boot it to Windows,

and then you can tell, then you can reboot and automatically boot to Windows because SD boot will then know. It implements, of course, a bootloader spec. With limits, it only supports invoking EFI binaries, nothing else. I mean, that's totally okay, by the way, if people do this, right? Our primary interest with the bootloader spec is that we get people to accept that

as what to unify on, and then, of course, we are completely aware that on different architectures, different firmwares, there are different sets of execution environments you want to support, fine, do it, and ignore all the other boot entries. We ignore, basically, all boot entries that do not match our expectations about EFI.

What SD boot also has as a nifty feature is that it actually automatically discovers Windows and Mac OS installations on the same hard disk, which is super awesome, right? It does that at boot, right? This is very different from how distributionists did this with Grub, right, like where you have this humongous, horrible script that collects all kind of data from your operating system to generate the Linux entries,

and then goes on and tries to probe all system partitions for Windows or Mac OS, and then generates some magic, weird programming script out of this that is then processed again with M4 or something like that, and then you get any output. This is so much easier, because this thing actually, while because EFI is so much easier to work with,

during boot, it just looks like, hmm, is there also Windows installed? Is there also Mac OS installed? Oh, let's add a menu entry for this. It requires zero configuration. It's just, if it's there, it shows up. It has a couple of other things as well, like, for example, if you have the EFI shell, which is like the DOS prompt, but just for EFI installed, we'll automatically find that too, add that to the boot menu.

It also has, if the firmware supports it, and all modern firmwares do, it gets a boot into firmware menu item, where, like, we nowadays live in a world where booting can be very, very quick, so most of the firmware manufacturers did this by not necessarily initializing all the keyboards anymore,

and particularly if you have USB ones, that makes it difficult to enter the firmware menu this way, so it's very, very useful if at least the bootloader menu, the one that we implement, gives you the ability to return to the firmware menu. So you basically, yeah, if you manage to get into SD Boot, into the boot menu, there's an item, you click on it, bam, you're in the firmware setup.

As I mentioned that already, it doesn't do anything else when running EFI variables. It's one EFI binary, you just drop that into your ESP, and on next boot, it will automatically find these drop-ins, it will automatically find Windows and Mac OS, blah, blah, blah, blah.

I showed it in the menu, you pick something, it boots it up. There's a tool called boot control install, which does that for you, right? It's super duper stupid, it just takes this EFI binary, like the compiled version of SD Boot, takes it from some directory and uses a lib where it was shipped in the RPM, and then does a simple CP basically, and puts it into the ESP, and that's...

I mean, it does slightly a bit more, like it creates the drop-in files, directories for you, but mostly to make it beautiful, not because that was necessary. It's totally sufficient if the first one creating the boot entries actually does that. But, yeah. If you want to update the thing, there's boot control update.

Updating is what you would do if you installed a new version of SD Boot that has some newer features, and yeah, it's a little bit smart, like it checks, it looks at the EFI binary, reads the version out of it, like when it was compiled, what system new version it was compiled from, and only if it has a newer version will update this.

The idea basically of this is that the RPMs of SD Boot that are shipped with various distributions, like Fedora, SUSE, whatever, if they should all adopt this, which of course they should, that they can all just call boot control update from the RPM scriptlets, and yeah, the newest version of SD Boot will always win and be automatically updated

to make this fighting around the bootloader main binary unnecessary. It has a boot control status that tells you if it's installed or not, and it can also tell you which boot menu entries are actually existing right now,

so that you can know while you boot it into Linux which are the boot menu entries that will show up if you would reboot right now and would see the boot menu. Yeah, they are pretty trivial commands. Just to mention that they have a couple of other nice features, like for example the command line editor, drop has that too, nothing too fancy.

EFI has this nice concept called EFI variables, which are a way how the bootloader can communicate with the OS and pass data in both directions. We define a couple of those, for example, to select the next entry to boot into. I already mentioned that this is useful for implementing boot into Windows from Linux. You click on GNOME, the button somewhere boots into Windows and does just that.

It has this in two ways, just for the next boot or for all future boots. You can also, as an EFI variable, select the boot timeout, which is just how long the menu is going to be shown before the default menu item is selected. This can be used in various ways. For example, you could also add a menu item to GNOME that says boot into boot menu,

and all it does, it changes the timeout from 0 to 15 or something to make sure that the menu is actually visible to the user. I already mentioned that briefly. There are also EFI variables for performance data specifically. If you want to know how quick your system boots up,

you want to know how much time was spent in the bootloader and you also want to know how much time the bootloader spent waiting for user input before the user pressed enter because that data is usually not that interesting to you because it just means how quick was the user to react. We passed all the data along and actually system deanalyzed.

If you have applied with this, it actually reads that data and automatically makes use of this very useful information. What's also very interesting is it sets an EFI variable referencing the used ESP, which is something that is weirdly missing in the EFI specification that the operating system otherwise has no way to figure out

which is actually the ESP that was used for booting because there can be multiple options for that. Let's say you have the hard disk rather than ESP but you also plugged in a USB stick that also contains the ESP because it's the Windows Live Media or something and it's not always clear which one is the one that's used. We set an EFI variable that tells us that.

It's actually what we use to then mount slash EFI as I mentioned earlier. There's also an EFI variable that enumerates discovered entries just that tells you what was actually there on the previous boot that it found and usually tells you also if there's a Windows or Macos installed parallel.

It's kind of similar to the boot control status output that I mentioned earlier. The only difference is this shows what was actually there when the boot loader was last running while boot control status tells you what is right now there. There's also an EFI variable that declares the feature set of the boot loader

like which of these options actually supports. This is really nice so that Gnome can show the menu items that I mentioned when they're available but can suppress them when they're not. Actually, most of the stuff that's on this slide is not specific to SDBoot. We kept this entirely generic so that any other boot loaders can implement that too.

So far we're not aware that any of those do. If boot loaders implement this, they get this wonderful benefit that systemd at various places actually will start making use of this information. For example, systemd analyze will show you this among the normal performance data that it shows

and system control reboot has this option reboot into boot menu item that will then suddenly work. But there's a little bit of the grub people there not interested in this kind of OS integration. We did our side of making this open but so far there wasn't any interest from the other side.

So far about the basic feature sets. I hope you got the basic idea of what we're doing here. I would like to clean up how we do boot loading on Linux a bit and dumb it down substantially and diminish the risk how the various players in this field fight around common resources.

I hope you also get the idea that the specification that we did is really supposed to be something that systemd makes use of heavily and that we really would like if distributions would adopt across the board and that while we implement them in stdboot they're actually not stdboot specific and any boot loader can implement them

even without ever mentioning systemd by the way. There are questions. Now would be a perfect time to ask questions.

Do you have any plans to implement verification of secure boot or encryption, encrypted boot partitions, that kind of stuff? That is a very good question. I think this kind of verification like secure boot is very very important how we should build our operating systems.

It is the reason why this type 2 boot loader entries exist. The unified ones where you take a kernel, you concatenate an init ID to it, you can add a boot splash actually to it, you can add some little metadata to describe the things and you can add a kernel command line string to it.

That's all combined into one EFI file, one PE EFI file that you can run and then the good thing is if you do it this way then you can take this whole file and sign it with a PE sign for seccuboot. So that basically means that if you want a fully secure boot path all you have to do is you sign seccuboot itself,

you generate these unified binaries, you sign those and then the init ID that's inside of that needs to verify the root file system but then that's already all you need for having a secure chain. So it makes this so much simpler because there's not that many components that have to verify each other.

It's just that firmware verifies seccuboot, seccuboot doesn't even verify anything, it just asks the firmware to verify the unified kernel image and then the kernel image is just the root file system and there you go. So I think it's very important but our approach to this is we don't do anything, we just make sure it's in a very friendly way so that the firmware can do this for us for free.

So, sorry, my question is rather about, I guess it's an asshole question because it's about the chances of adoption in the sense of, I mean, it's not a bad idea obviously. You need to get this into GRUB realistically, right?

Well, I mean, so yeah, GRUB, I think GRUB is a problem, not a solution. And also file system drivers and user space? Yeah, what was that? You only do with EFI, right? Well, the bootloader specification is completely generic, right? My point being, for SD boot to be used instead of GRUB,

must probably do something similar, right? No. No. So the key really is that we agree on this dollar boot petition and that everybody puts the stuff there. And ideally on EFI, that can just be the ESP. But if that's not possible, you have a separate petition. But inside of that, you have VFAT.

VFAT is something that EFI reads anyway, Linux reads anyway, GRUB reads anyway. Everybody, that's kind of like the lowest common denominator that everybody can agree on that is already built into hardware that even the freaking Raspberry Pi weird firmware actually supports some form of VFAT.

So the idea really is just use that. You have to have that anyway on EFI machines, right? Like you cannot boot EFI without an ESP around, right? So the idea is that, yeah, we just define one way how to define that stuff and one directory where you put that stuff. That's it. Make sense?

But, yeah, I mean, your earlier question regarding GRUB is I wrote that patch as mentioned that added bootloader spec support to GRUB. But that was four years ago or something like this and didn't go in and I didn't even want to fight that stuff. I think, yeah, I would really like if distributions would adopt that. We never talked about this public so much.

It's like only a second talk that I'm doing about this. So it's definitely my intention to push this harder. And, yeah, I know that this is, like, lots of people have lots of time and love invested into GRUB. I think the approach of GRUB is just too complex and too fragile

because it's in, like, at least the way we have implemented this on Fedora and in RHEL. It's like a programming language that generates a script that then generates a script that then ultimately generates a script that the bootloader executes as a Turing complete language and just like, Jesus Christ, that's so wrong in every way.

So this is supposed to be the complete antithesis to any of this, right? Because there is no programming language in this. There is no shell scripting in this. There is nothing. Let's just agree on one partition, one directory and everybody just puts some stupid files in there, the way how RPM and DPKG figured it out, like, 25 years ago or something.

If I wanted to modify or pass the kernel command line parameters and I'm happy to use either type 1 but more interestingly type 2 binary, can I do that? And is it like an EFI app slash-args or what is it?

So it's a very good question. So for type 2, the ones that potentially are signed, we probably shouldn't even allow that at all. Like, if you turn on second boot... You should measure them into TPM. Sure, but then you can as well sign them, right?

Like, that's no different, right? There is a big difference between signed and measured. Sure, anyway, but the model that I would assume there is that if you turn second boot off, you don't want the user to make changes to this, right? You want to turn on secure boot and allow some changes and make policies based on measures of whether what was passed on.

But my assumption is generally that if you lock everything down, then locking down the kernel command line is one of those things. That said, there is also type 1 stuff and I know that people also want to be able to use type 2 without this stuff, right?

If so, they first of all have, of course, the option to make the changes interactively, right? At boot. But that's an SD boot implementation feature to change the command line. Sure, but every bootloader does that. Like, GRUB allows you the same thing, right? Okay, yeah, yeah. The other thing is, like, we have been talking about adding at least to SD boot now

a EFI variable that is just read during boot and appended to the existing stuff, right? So that you can override the defaults if you want. And then we would probably add a logic that by default on secure boot we don't do this, but on other cases we do. But then you basically could do something like, for example,

that when you shut down, you add to this EFI variable that, like the F force FS check mode or something, then you reboot once and we can even do it like this, that we have one variable that gets removed on the next boot so that it only applies once and one variable that applies forever. So we can very nicely do the thing where you just set the force FS check for the next boot

and then not for the subsequent ones without... That's something actually nobody could do before, right? Like, if you want to set FS check for the next boot once and GRUB is messy, right? So, yeah. So do you have a specification support of boot counter and rollback situation? This is actually, I mean, if I had twice the amount of time, this is what it's about.

Yes, SDBoot supports that. There's another specification that is very closely related to the bootloader spec that adds all that, where you basically can specify boot this automatically five times, give up if that happens, then go to the next one. My recommendation is read this documentation. It's a very simple mechanism.

The count is implemented in the file name for us. The reason for this is because we hope that, given the shitty VFET drivers in the firmwares, we were looking for a simple way to change the file system that has the least chance to crop the file system if the file system driver is bad.

And the good thing is that if you rename a file on FAT, there's at least a very good chance that this can be done with a single block write, which we think is the biggest chance, but of course it's a bet. Anyway, if you want to know a bit more about this, read the map page. Hey, so two questions. One is VFET is not a requirement for BLS, but for SDBoot, VFET is a requirement, right?

Not really, you know, on Mac OS, like on Mac machines, they actually implement, like what's the Mac OS file system, HFS Plus driver in the firmware. But there are going to be file system requirements depending on... Okay, it's more complicated like this than this.

So I had this long discussion inside of Red Hat in particular where people said, oh, VFET is so evil, you shouldn't use VFET, that's not safe, we need to use a proper file system to do this. I'm not sure how much I agree to that idea, but regardless, the firmware will generally only start VFET, and that's fine.

As I mentioned, there's a dollar boot and can either be ESP or can be this other petition. If you load a user space file system driver for any other file system of your choice from the ESP before or by SDBoot, then this allows SDBoot to look into the other petition of that type and looks at stuff there.

But SDBoot is never going to maintain an XT2 driver, whatever people want there. What we probably will add is some kind of drop-in directory where you can add file system drivers as much as you like, then you maintain the file system drivers, we don't have to give a fuck. But we'll look on those petitions.

Anyway, I think my time is very much over. Thank you very much. If you have further questions, you know where to find me.