 Yeah, welcome to the talk about Linux boot. Maybe you heard of it. It's let's say a firmware replacement for a current firmware. Or let's say it's not a complete replacement. It replaces most of your parts and is built together with your current firmware. For example, UFI core boot or U-boot. Thanks to Tram on Hudson providing these slides because yesterday I got the information that I can do a talk or I have to do a talk here. After someone answered his talk, so I'm a little bit unprepared. You know, I didn't do so much preparation, but it should work anyway. So let's start. So this guy is Ron Minich. Maybe you can see him on the left side. He worked a long time on data setters for the government and also now for Google. And he was also the founder of core boot together with Stefan Reinhauer. And on some point they started a long time ago the so called Linux BIOS. Maybe you have heard of it. It started in 1999. And yeah, after some time they had to rename it and since 2008 it's core boot. Yeah, basically that's what happened in the past and Linux BIOS itself. The idea was that you use a Linux kernel instead of rebuilding your whole firmware with let's say your own implementation. And the problem was that in the past there was not so much code in the Linux kernel. We had bad graphics drivers. We didn't have printer support, whatever, you know what I mean. So the driver stack was really bad. And so they couldn't do that and yeah, they did their own thing. And today it's called core boot. Yeah, you also have this today in the most laptops you use currently. It's called UEFI Unified Extensible Firmware Interface. And it was introduced by Intel a long time ago before it was called EFI and used by Max and later it was called Unified Extensible Firmware Interface and was introduced by Intel and together with Microsoft. Currently, the firmware stack or let's say the UEFI stack looks like this. You have the security phase which does some kind of security stuff. Then you have the pre-AFE phase which is platform initialization. That means that you have the Firmware support package for example. And it does memory in it and whatever. And after that, you have memory initialized. And then you have the DXE phase which is basically drivers and so on, environment, whatever. And then you have also a boot device manager afterwards. And then it loads your bootloader. You can see that first final OS bootloader. And after that you have your operating system or whatever. So this is the standard graphic and what we plan to do is that we have something like this. So we try to rip out everything, yeah, let's say after the pay phase. So we need the pay phase, normally if you don't have memory, you can't use the Linux kernel. That's not working. So we could also do the memory initialization inside the Linux kernel, but that's not a good idea. And you would have something like additional init stuff. And that doesn't make sense. So we stay like this and just have the sec phase and the pay phase. And afterwards we load Linux. And yeah, then you can load your operating system. For example, Linux, we could also load Windows. It's not a problem at all, that can work as well. In terms of security, so if we look at the UFI boot flow, it looks really complex, to be honest. Maybe this part, the sec and pay phase is not that bad because it's really small. But if you look at the DxE phase, it's extreme huge. And it depends on the vendor how much modules are added there. So if you have a vendor which adds thousands of modules there, they have dependencies to each other. And that's also why your boot up is so slow. If you make a dependency graph out of the DxE phase, it's horrible. So they have a really long, so the boot phase takes a really long time, also on servers. For example, you rate 20 minutes to boot up your server. That's not really good, because a lot of time and money. And also the DxE phase can introduce a lot of bugs, because you have a huge amount of codes in there. And that's normally not a good idea. You can look how many modules you have, there's only a few modules. You have different stuff in there. And sometimes vendors forget to remove stuff, and then there's more in it, and you don't need it. And that's normally not a good idea, because you want to have a minimal tstb, which is a trusted computing base. So keep your trusted computing base always small, not big. Also, in this schematic we have the GRUB, which is our boot loader, for example. But also GRUB has a lot of code, and it's mostly C. And in general, this are the biggest problems. You don't have defense in depth, you have weakest links, and there's a lot of code in it. And if you look, we have compared some things. So you have UEFI, for example. You have GRUB, you have the Linux kernel. They all implement, for example, what is it this time? It's the TCP stacks. They all have a TCP stack. So UEFI is a TCP stack, the GRUB has a TCP stack, and your Linux kernel has a TCP stack. So it's code duplication everywhere, really everywhere. And that's not a good idea. Same goes for FAT driver, file system driver, and whatever. So you can see that USB and FAT, so whatever. It's a lot of code duplicated over some time, and that's not really good. So on the Linux kernel side, we have nearly unlimited contributors on GitHub. If you look at the EDK2 project, it's around 140 contributors, and then we have GRUB with 100 and C. So not so much GRUB, and that's the problem in general. So the most developers doing Linux work, and it's better maintained. If for GRUB, for example, you only have maybe one core developer, some other developers working around, but they don't care so much about the quality of the USB stack or the FAT file system, rather, you know, and then you have bugs in it and security holes. And that's the problem. Yeah, currently, this is an interesting picture. So with CoreBoot, we had Linux boot since 17 years, because you always can load with CoreBoot a Linux kernel. And normally, that makes sense. You can use it on some devices, and it works fine. But today, it's changed the way of firmware development change. We've got more and more code everywhere, and it's a general issue that we have so much code currently which initializes the platform itself. So Intel started to have a project called InterFSP, which is the Firmware Support Package. And this Firmware Support Package itself does a ram initialization, and afterwards, you only do a small platform in it, and then you can directly jump to the boot loader. The FSP can currently be used with CoreBoot together. Afterward, so you see this with the examples, you have the pay and the sec phase, it's around, so we don't have it in CoreBoot, but the same level. You have CoreBoot, the FSP, and afterwards, you have the board in it, and then you load Linux boot. Same goes for UEFI. You have the pay and the sec phase. Afterwards, you load Linux boot. So Linux boot itself, it's independent from the Firmware. It's the idea of having the Linux kernel doing all driver stuff you need to have for example, if you have a data center, you want to have an TCP IP stack for loading, for example, images through Ethernet, or you have different other use cases. For example, you can do in Linux boot, you can easily use VJet, Mount TempFS, the whole memory, then you just download, for example, an X-server, inclusive a Mesa, through network, and also load Atom Editor, start it, and you have an Atom Editor in your BIOS, on the flash ship. So in the memory, you can unpack it. So I only want to say, all the things you can do with the Linux kernel is really great. You have a small system, you can reduce it, and you have two megabytes of Linux kernel loaded by the Firmware itself, yeah. And that's how it looks, and maybe you saw that on the Linux boot home page. So the basic stuff is done for the RAM in it, which is the UFI pay, core boot ROM stage, and Uboot SPL, and afterwards you load the Linux kernel, including an init-RAMFS, and then you can jump into your operating system or do other things inside your Firmware. Yeah, that's how it works. So yeah, I'm done. That was short, but yeah. So if you have questions, you can also, there's currently, there's a comment on core boot, which you can use, there's already links been integrated in a better way, and you can also go to the Linux boot GitHub and the linuxboot.org home page, yeah. And now questions. Is there still some stage where option ROMs from hardware get executed at some point? Currently not because you don't need to do that anymore, because you have the Linux drivers. So the funny thing is, for example, VGA option ROMs, or graphics in an option ROM, you can do that with the Linux kernel. You don't need the option ROM anymore for the intro driver, for example. If you have something like an AMD driver or whatever, you can additionally include DxE files or option ROMs and loads them. Works as well. So if we talk, for example, I can maybe extend it a little bit more in detail. We have, for example, the system management mode. You could ask yourself, what's happening with the system management mode? We can do that inside the Linux kernel, and later have some application doing interfacing, whatever. So that works as well. Regarding device tree integration, which is mostly used under x86, PCI device tree integration, it's done inside the Linux kernel already. You can just check an option and it does it. So there's no need for, let's say, for core boot ROM stage or UFI DxE phase, whatever after U-boot SPL comes, you know, you can just use the Linux kernel. Don't duplicate code. It's a bad idea. Currently, you can do this with core boot as well, sure. And if we talk about UFI currently, we are on the way integrating that. We have already, I guess, three different types of servers running. They started with server work, so maybe it can take some time. And also we need support from Intel and other, let's say, vendors because it needs to be inside the specification, otherwise you can load something different. And you know, if you have Intel boot guard or any protection mechanism which protects the firmware itself, you can change the firmware, sure, because it's signed. But if you have an option to load it into the firmware itself, to some concept, then it works. So we are currently on the way doing that. In discussion with them and see what we can do. Yeah. Oh, sorry. Yeah. Okay, so you're saying keep your trusted computing base small, but the Linux kernel is enormous. Yeah. So is there any way to sort of get a smaller base that can then verify things later on? Yeah. So the trusted computing base for the unit. Repeat the question. Repeat the question. For the mic. Okay. So the question is if the Linux kernel itself, it has a huge TCP USA and how to make it smaller, for example. Yeah. So that's how it can be done. So I got stripped down the Linux kernel to 1.6 megabytes. And if you look into the RFI code, it's more. So for Cobut, it may be less. Sure. The new kernel currently is really big, but it's not that big issue because it doesn't open interfaces. It may initialize as only drivers you need. And the core structure, which is really huge, it's mostly, let's say, set up for the kernel itself. It's not loading drivers. You can make tiny config. And if you have done it, then you can easily strip out everything you need, or you only add things you need there, and then it's really small. That works. Sure. Port it to a new UFI-based platform. So how much work is needed to port it to a new UFI platform? So we did that really fast. So maybe you need a few days to do that. Sometimes it's really easy because you just strip out the DXE modules and then you just throw in the kernel itself and it works out of the box. Sometimes you have problems, but it depends on the vendor, what they did. And sometimes they did some wired stuff, but so if you have a predefined interface and we are allowed to do that, then it's not a problem at all. Otherwise it takes maybe a few days or one week. Yeah. Yeah, so how do we enable one-bot components? What do you mean by that? I like AXDI mode also. All the options that are available from the setup. This can, yeah, it's okay by a setup, okay. So this can be done normally by parts of it. So you don't have to strip everything out of the UFI. You can also keep some DXEs or write your own DXE, which does the job. So that's what we're currently doing. Maybe you have one DXE, which does the job for UFI. For Colwood, it's not a problem. You have the code. You can just modify it, let's say, or do your own implementation, and then it works. It's not a problem at all. You can do it at UFI layer. Works. We can also write the driver for Linux itself. Yeah. Yeah. What is the storage options come from? Yeah, what is if it's from a third-party render? So yeah, then you have to reverse engineer that at the moment, but maybe you get some support and we already did that. So it's not like you can't do it. It's the first time it's some work, but I can tell you more. So I'm not the UFI guy, you know, and we have Trammel Hudson working on this. If you want to get some more information, you can ask Ron or Trammel Hudson. They do the whole work. I'm currently more on the Colwood side, but I'm also looking into the UFI stuff. Yeah. So what do we have currently and for the inner drum FS? The inner drum FS itself can be every inner drum FS. You can load your own inner drum FS. We currently use UWOOD and UWOOD is a Golang written inner drum. Maybe you want to talk about that. That's your part. So he's one of the UWOOD developers. Yeah. Can you use my phone? Yeah. Yeah, I'll be very quick. So one of the possibilities. Yep, on the camera. So one of the possibilities in UWOOD is to have whatever drum FS you want. And one of the drum FSs we are working on is called UWOOD, universal root. This drum FS is basically an open source drum FS written in Go where you can actually have your tool chain, which is either a busy box like tool chain or a source code in your firmware that you can modify or compile and apply on the firmware chip itself. And from there, you can literally W get your provisioning image and boot your installation software or you can boot from disk or you can KX second to your kernel or do whatever, literally whatever you want. You basically have a full Linux environment with a shell and from there you can compile your own code, bring any existing, already existing Linux tool, anything like that. So basically you are literally limited to whatever you can download in your system and run from a Linux kernel, which we know is pretty, pretty broad limit. And Linux boot is also linked from the, sorry, UWOOD is linked from the Linux boot website. So that's very interesting project. Go have a look at that and we are looking for Go developers that want to make it better so we can get a UI, better tooling, et cetera. But you can also use, for example, the heads in a drum FS, it's already there. So they are different in a drum FS also and do whatever you want. You can also just implement something in Rust or C. Have fun. So it stays with something and it's failed. What is the fail set? How can I restore it? How can I get back to a secure, good boot in state? So this is, so you remain, that you have, for example, in recovery mode. So they are different options. So if you have control over your own init ramf as you can implement it there, in theory you can also use firmware mechanisms like for core boot, we have vboot with some failure safety. So it will just jump to another image inside the flash itself and execute that if that works and if not the read only part that depends on the firmware. So you can implement that in Go. Currently it's not there or any other language and all you do it in the firmware which is currently, yeah, the normal way, how you do it. If you want to get core boot on it, you have to first do the hard, so the basic. So you need to check if the platform in it is already available for your architecture and if it's available you have to adapt that and if we talk about UFI for example, it's already there. So you just pull the UFI image, just strip down every DXE modules, put the Linux kernel in it and just start it. That's what you do with UFI. On the most laptops there is no core boot installed. You know what I mean? So you can do more work on the core boot site or you just pull out the UFI image, modify it and put the Linux kernel in it. It works as well. It's easier for you because you don't need to understand how the hardware in it works. That's the thing. So that's why we're working with different firmware. We don't care if you use core boot or UFI or UBOOT or whatever, yeah. Can you give some news about this Linux Foundation announcement, for example, and the other question is can you actually buy it in the stores and probably on the server? Is it a possible thing or? Yeah, so let's say, so the question is if you can buy it and where to get it and when it's done, the thing is this always takes a long time. To be honest, modifications in the firmware level, it's more like decades, yeah. Maybe you can buy it soon. For example, currently there's a server hardware out there from the compute project that works with Linux boot. You can already download images, just flash it on the chip and it works. So, but until we do laptops or desktops, that's a different level, you know. Maybe you can do that, but then we need to have vendors as well, which allow us to flash firmware, for example, because normally they're assigned and it's not allowed, so it can take a while. Maybe it's adopted there, but we will see. That always depends on your vendors and to be honest, just buy from vendors which are really, let's say, which try to be more open. For example, if it's not perfect, even then, bipartisan hardware, you can buy Chromebooks by whatever, which includes open source firmware, you know. You would, laptops or whatever, just use that instead. That's my opinion about it. So, because otherwise it's never changes, because you're only a small amount of people and you have 7 billion people out there, they don't care about it.