Document porting linuxboot to a new mainboard about linuxboot HOT 6 OPEN

Thanks for the questions!

I'm currently looking into documenting more of the procedure is done; for a start, the general answer is: You need to figure out what you can remove. This repo and https://github.com/linuxboot/fiano bring the tools for assistance, especially utk (a command from Fiano).
The LinuxBoot book gives you a head start:
https://linuxboot.github.io/book/implementation/#how-do-you-get-linuxboot-on-your-hardware

We have an app (work in progress) that assists you visually with a look at your firmware image: https://fiedka.app/

Please let me know if you are interested in joining the documentation effort, or what equipment you have (flash programmer, specific mainboards, etc). The workflow will diverge a bit for Intel (with ME specifics to gain space), AMD (likewise, with PSP), and other vendors. I personally have a bunch of AMD desktop mainboards from various vendors as well as Intel laptops.

from linuxboot.

see also #31

from linuxboot.

Thanks for the links :)
Do you actually need to remove something? One of linuxboots goals is to slim down the UEFI image but are there any changes required beyond "5. Replace UEFI Shell code section with Linux kernel and associated initrd (change part of one thing)"
to get a kernel + initrd booting directly from flash provided you have enough free space?
I'll probably can't help too much with documentation (otherwise I wouldn't ask all these questions) but I have a flash programmer. So if there is some easy way to make some tests I'll probably give it a try.

from linuxboot.

Do you actually need to remove something? One of linuxboots goals is to slim down the UEFI image but are there any changes required beyond "5. Replace UEFI Shell code section with Linux kernel and associated initrd (change part of one thing)" to get a kernel + initrd booting directly from flash provided you have enough free space?

That's correct, given enough space, simply replacing the shell and/or boot menu would suffice in order to execute something custom - which could as well be run from said shell or menu then, so we'd gain quite little only.
Beisdes that, having enough free space is usually not the case. And as you write, one goal is to remove the untrusted parts that are not necessary, not only to gain space, but also for security.

I'll probably can't help too much with documentation (otherwise I wouldn't ask all these questions) but I have a flash programmer. So if there is some easy way to make some tests I'll probably give it a try.

Well, I am about at the same stage - part of the job is to figure things out. :-)
I will start with something simple on real hardware, just not sure yet when. I'll let you know here. Thank you!

from linuxboot.

You could run the linux kernel from an uefi shell, but you first need to load it from somewhere. Having some kernel+initrd in the EEPROM itself would already be a versatile tool for all kinds of stuff compared to what you can do with just the official UEFI image. Depending on the size and what you want to do with the machine you could even put the whole OS in read-only flash memory.
Some mainboards come with socketed EEPROM chips, mostly for servers. Some other vendors provide a header for connecting pins which could maybe be used (+removing CS pin of on board SPI?) for attaching a chip with larger size. This could make testing a bit easier.
Is there some vendor to maybe avoid completely? Or some ways vendors could make it impossible to boot a custom BIOS? I think only Android/Apple locks down the devices so you can't even boot a custom UEFI.

from linuxboot.

Sorry for the delay - yes, OTP (one-time programmable) fuses and burnt-in signing keys can keep you from running custom firmware.
There's Intel Boot Guard, BIOS Guard, analogous AMD stuff etc.

FYI: The book now runs live at https://book.linuxboot.org/

We'll extend that over time, it's deployed from the https://github.com/linuxboot/book repo.

from linuxboot.