Is two kernal needed for linuxboot

[Wenyi Xie]

Hello everyone，

I'm new to linuxboot. My first question is that is two kernal needed for linuxboot, one used for replacing some DXE in board.rom and another one is the real product kernal.

I checked code of linuxboot, and found how DXEs are extracted from board.rom. My second question is how to using drivers in kernel instead of the extracted DXEs.

[Ryan O'Leary]

Hi Wenyi,

That is right -- There are two Linux kernels. The first kernel is on the flash chip. It loads and runs a second kernel. The second kernel might be loaded from the disk or over the network. Once the second kernel is found, the kexec (https://linux.die.net/man/8/kexec) command is used to run it.

Note, there are some variations of this. For example, you can reuse the first kernel as the second kernel.

As for the drivers, the DXEs which get removed are completely discarded. The Linux kernel has its own drivers.

There is a good high-level overview here: https://github.com/linuxboot/book/blob/master/intro/README.md

- Ryan

--
You received this message because you are subscribed to the Google Groups "linuxboot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/aa3a3e74-31a5-4aad-81ef-e62fc2a7916bn%40googlegroups.com.

[Lao Shaw]

U-boot and Linux works just fine on so many systems, what's the real need for yet an extra linux-kernel-with-initramfs in the middle? what's the real benefit?

In the case of U-Boot, again it initializes DDR/Storage etc and passes the control to Linux kernel, which fully brings up the system and run your workload, why do I need another Linux kernel as a "3rd-stage-bootloader".

I'm new to linuxboot too. Thanks for any insights.

[Lao Shaw]

Read a bit more, linxuboot essentially replaces UEFI, that makes sense now. Thanks.

[ron minnich]

Yes but. Consider the case where Linux is embedded in flash and there's no need to boot another kernel. Then you need not boot another kernel. This is one of the use cases of u-root: an embedded in flash kernel with a go based  initramfs. 

There are no rules or requirements about how you use Linux, Linux boot, and u-root. On the nichrome project, we built a distro for Chromebooks, where we had one u- root in the initramfs and a different u-root in the root file system: two u-roots. GitHub.com/u-root/NiChrome. In this case nothing was embedded in flash, and there was no kexec step.

For microbmc, the kernel and initramfs embedded in flash are all you need. There is no kexec. 

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/354649e9-32ff-44c3-9cc3-8b0a6226b915n%40googlegroups.com.

[David Hendricks]

Hi Lao,

U-Boot, like most firmware that runs on complex SOCs, has multiple phases: pre-DRAM, post-DRAM, and some kind of environment. In U-Boot's case this is the SPL and U-Boot environment. UEFI has its SEC, PEI, DXE, and BDS phases. coreboot has its bootblock, romstage, ramstage, and payload phases. LinuxBoot is intended to be used as the last phase, e.g. in place of the U-boot environment, UEFI BDS, or coreboot payload.

The main advantage is that Linux kernel typically has drivers, networking capabilities, filesystem support, etc. needed to load the target OS. It also gets far better support and much more scrutiny than most firmware, and is obviously open-source unlike some firmware out there (particularly in the UEFI world). Along with the kernel you'll have an initrd which can contain whatever environment you want - Busybox is a popular choice, but there are others such as u-root (that Ron pointed out) which are interesting in various ways.

In short, the goal is to simplify the role of the firmware. Ideally the only driver that the firmware needs is for its own boot media so that it can load its own code and also the LinuxBoot embedded alongside it. For everything else, let Linux do it!

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/354649e9-32ff-44c3-9cc3-8b0a6226b915n%40googlegroups.com.

[Lao Shaw]

With linuxboot, we will need larger storage space(e.g. 8MB), which is expensive on low-to-middle range embedded systems, but for server rack or data center or OCP systems this should be OK.

Is linuxboot just a regular kernel without too many manual tweaking(just downsizing by removing unnecessary parts under make menuconfig)?

Will linuxboot project designate certain (LTS) versions or everybody picks their own at will?

What about security fixes along the road, normally firmware is expected to have much less frequent updates on  a running system.

Thanks,

Shaw

[Ron Minnich]

On Mon, Aug 30, 2021 at 6:24 AM Lao Shaw <laos...@gmail.com> wrote:

With linuxboot, we will need larger storage space(e.g. 8MB), which is expensive on low-to-middle range embedded systems, but for server rack or data center or OCP systems this should be OK.

Low to middle range embedded systems  I use  come with at least 8 MiB, easily large enough for linuxboot + u-root; see the digital loggers atomic pi for example. github.com/linuxboot/mainboards/digitalloggers/atomipi. But 8 MiB is rare, typical sizes now are 16, 32, or larger part.

 

Is linuxboot just a regular kernel without too many manual tweaking(just downsizing by removing unnecessary parts under make menuconfig)?

typically,  companies start with a tinyconfig kernel and add very small number of things. I have made linux+u-root images as small as 1.3 MiB.

 

Will linuxboot project designate certain (LTS) versions or everybody picks their own at will?

Everyone has different requirements. Linuxboot project does not choose kernels for everyone. Google is focusing on LTS for linuxboot, however.

 

What about security fixes along the road, normally firmware is expected to have much less frequent updates on  a running system.

 Do you have evidence about update frequency of typical systems? What frequency do you expect? Further, given the many documented exploits of UEFI, why would you expect low update frequency?

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/05ebe114-7b42-402a-8e39-5e651c822480n%40googlegroups.com.

[David Hendricks]

Will linuxboot project designate certain (LTS) versions or everybody picks their own at will?

For now we're mostly interested in tools, testing, and helping people to implement it on their hardware. We're not dictating any particular version since the major companies that have adopted LinuxBoot often have their own kernel teams targeting specific versions.

What about security fixes along the road, normally firmware is expected to have much less frequent updates on  a running system.

That's a great question. Anybody (or any vendor) can be either negligent or responsible when it comes to patching. The important point here is that if your vendor falls into the former category then can you replace the firmware using readily available, mainstream components? Or if you are a device vendor, is it easier/better to keep up with the latest firmware patches by using the latest LTS kernel release?

Another question to ask is: What does your firmware actually need to do in order to boot into your target OS, and how do you maintain it? One of the challenges we face with modern firmware is bloat/features such as custom network stacks, crypto libraries, etc. Here's a recent example where >100 Dell models were found to have a remotely exploitable UEFI-based remote update/recovery tool: https://eclypsium.com/2021/06/24/biosdisconnect/

Dell is a reputable vendor that took steps to mitigate that issue in their firmware. However, our observation is that many hardware vendors lack the will or the resources to patch such vulnerabilities and we're better off just using embedded Linux instead where we have full visibility and control.

To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/05ebe114-7b42-402a-8e39-5e651c822480n%40googlegroups.com.