20 KiB

Raw Blame History

HP EliteBook 2760p
HP ProBook 6360b
HP Revolve 810 G1
HP EliteBook Folio 9480m
HP EliteBook 8770w
HP EliteBook 820 G2
HP EliteBook 840 G2 (not in coreboot yet, but should be similar to 820 G2)
HP Z220 CMI and SFF mainboards
Dell OptiPlex 7010 and 9010
Dell OptiPlex 7020 and 9020
MSI PRO Z690-A mainboard (supported by Dasharo, not sure about coreboot) - also, Dasharo supports several more mainboards that aren't in coreboot proper.
KGPE-D16 and KCMA-D8: use the Dasharo fork of coreboot, instead of coreboot 4.11_branch, because Dasharo's version is much more up to date and more reliable with raminit. D8 isn't supported by Dasharo, but it's not much different code-wise to the D16 mainboard, so differences in coreboot 4.11_branch could be adapted to provide a Dasharo port.

FSDG boards

Not yet supported, but interesting for the project. Separated thus:

already supported by coreboot:

ASUS P5Q mainboard (ICH10 / i82801jx), known variants, e.g.: Pro, C, L-Pro, SE
Scan coreboot code for ICH9/ICH10 systems, or boards with x4x/gm45 based northbridges. Many of these can boot blobless.

Dell Latitude/Precision:

Dell Latitude laptops: E4200, E4300, E5400, E5500, E6500, Precision M4400,

These typically use MEC5045 or compatible EC. Some may use MEC5035.

SuperIO: at least M6500 is known to use ECE5028. I have a bunch of these Dells at my lab, they are high priority for porting because they would be easily flashable, and blob-free configs (Canoeboot could also support them).

Other Dells (Ivybridge and Sandybridge)

Nicholas Chin is interested in these:

E6520
E6420
E6320 and E6330
E6220 and E6230
E5520 and E5530
E5420 and E5430
6430u
E5520m
E5420m

Most/all of these should be easily flashable, with the dell-flash-unlock utility, and many could be ported using autoport as a guide. Nicholas is working on these. They are left here for reference. If you have one of these, please contact nic3-14159 on the Libreboot IRC channel.

ARM-based CrOS devices

Alper Nebi Yasak ported several of these to Libreboot, but only the gru_bob and gru_kevin machines are known to be stable.

It would be nice to re-add veyron-based platforms, e.g. veyron_speedy - old, but still very useful.

The nyan, peach and daisy platforms were initially added to lbmk, but prematurely. They are talked about here:

https://libreboot.org/docs/hardware/#removed-boards

It would be nice in general to support more ARM platforms in Libreboot. None of these machines are as decent as the Apple silicon machines (m1/m2/m3 etc), but they're still decent enough for most computing tasks (and the Apple machines do not currently have coreboot support).

The actual coreboot code for these machines is thought to be reliable. The problem is that the U-Boot port is not yet stable across all these machines. Libreboot has Alper's proof of concept which works well on gru chromebooks.

Caleb is interested in the krane chromebooks, but has had problems with vboot, getting it to boot reliably on custom firmware builds.

OpenSIL and AMD Ryzen

Of interest: coreboot has started imported AMD's OpenSIL, to support the Ryzen-based chromebooks, and there is interest in adapting that code for Ryzen-based desktops. AMD Ryzen CPUs are quite powerful, currently among the best available at least on consumer-grade hardware.

UEFI payload

A UEFI payload in Libreboot is highly desirable, because it would basically enable any distro or BSD to Just Work.

MrChromebox distribution

MrChromebox is another coreboot distro, similar in spirit to Libreboot.

Of interest: Mrchromebox provides Tianocore-based UEFI setups on chromebooks, and we could probably integrate some of that in Libreboot. Tianocore is essentially bloatware, and really a liability for the Libreboot project due to its complexity, though MrChromebox targets a very different audience.

U-Boot SPL and UEFI on x86

Simon Glass has been working extensively on x86 support for U-Boot, to be used as a coreboot payload. This work is of interest to the Libreboot project, because we provide UEFI on ARM but not on x86.

U-Boot also provides SPL which can be used to execute other software in the flash, and it's often used to boot a Linux kernel; since U-Boot provides a UEFI implementation, it's perfect.

U-Boot is the preferred choice of UEFI implementation on x86, for Libreboot purposes, because U-Boot uses a coding style similar to Linux and can more easily import Linux drivers which are high quality, and Linux functionality in general, for anything that we need.

Since we already provide U-Boot on ARM (thanks to the continued work done by Alper Nebi Yasak), U-Boot on x86 would then create a situation whereby Libreboot is consistent across platforms, at least for UEFI-based setups.

uefistub

Currently under review in the coreboot project, this provides an incomplete UEFI implementation, but much more minimalist than the U-Boot one. It doesn't really do anything except provide the most minimal code possible, and then you can jump to a Linux payload in the flash.

For UEFI purposes, U-Boot seems more mature, and it offers other features like SPL. As already stated, this is the preferred UEFI implementation for Libreboot, but uefistub is listed too because it's interesting.

Linuxboot

See for inspiration: Heads project and Ownerboot project, these are other coreboot distros similar to Libreboot, but they provide Linux-based payloads. Also see more in general, the Linuxboot project.

Libreboot's build system is documented, see: lbmk documentation.

It's possible to provide a Linux system that runs from the flash. Linux can execute another Linux kernel, using the kexec feature. There are bootloaders that can make use of it, for example the u-root project.

Libreboot's current choice of coreboot payloads are:

SeaBIOS (x86 only), provides a traditional PC BIOS implementation
GNU GRUB (x86 only), provides a multiboot implementation, can boot Linux and BSD. This is the preferred default payload on x86, especially for Linux distros, because it provides many security features like GPG signature checking on Linux kernels, and password protection.
U-Boot (ARM only), provides several boot methods, we typically use the UEFI implementation but it also provides many different boot methods; the one that is most interesting is the SPL (secondary program loader) feature, which is essentially the same concept as loading a coreboot payload - together with something like the minimal uefistub payload, can provide a complete setup.

U-Root in particular (not to be confused with U-boot has parsers in it for GRUB and Syslinux config files. GRUB also has a parser for syslinux configs. This makes it a useful drop-in replacement for the GNU GRUB payload that Libreboot currently uses. Linux has much better drivers than GRUB, especially for things like LUKS2 and networking.

Ideas for how to implement in lbmk

Look at the lbmk documentation for context. The most logical way to implement Linux payloads in Libreboot's build system, lbmk, might be:

Re-use the current crossgcc handling in script/update/trees, which is used for coreboot and u-boot. Coreboot's cross compiler isn't very useful for general applications e.g. utilities, but it could compile the Linux kernel easily.
Separately to crossgcc, use musl-cross-make for the programs inside initramfs. Use this to provide musl libc, busybox and all of the userland applications in general. Musl-cross-make itself would not be used as-is, but adapted and integrated into the lbmk build system. The design of musl-cross-make is largely compatible with that of lbmk, because both build systems are written in shell scripts and with the same minimalist mentality. 72 source lines! At least as of musl-cross-make git revision fe915821b652a7fa37b34a596f47d8e20bc72338.
In each package defined under config/git/ in lbmk, use the current design but support specifying, for each one, whether or not to use musl-cross-make. The current design in lbmk already permits use of make and cmake, for simple projects, otherwise for more complicated setups, a dedicated script is written, e.g. script/build/grub for building the grub images (which runs automake in the grub build system), or script/build/roms which builds rom images.
A script, script/build/linuxboot would build the entire payload with u-root in it, but script/update/trees would actually build each package.

BONUS: the musl-cross-make logic could also be used to provide static linked utilities, so as to provide compiled utilities in Libreboot releases, reliably. We currenty only provide source code for utilities, which is not always convenient for users, especially for utilities needed alongside vendor scripts.

If done in the way described above, the current code size in the Libreboot build system would not increase much. It's mainly the addition of musl-cross-make. Most of the generic build logic already exists in lbmk, for projects that use cmake and/or make. It could be done with minimal complexity.

Flash size limitations

With a stripped down kernel, and sensible configuration, about 6-8MB of flash space would be required in this setup. The Heads setup is just under 8MB.

Why Linux in flash?

Linux has better drivers than GRUB, has netboot, and it's much more practical when you want to control the boot process. For example, you could more easily implement measured boot and make use of TPM-based security mechanisms.

For the everyday user, it probably doesn't make much difference if they're already happy with SeaBIOS, GRUB or SeaBIOS.

x86 implementation

Coreboot can directly execute it as a payload, but we would also execute it from the GRUB payload - if running from the GRUB payload, we could just provide it as a vmlinuz and initramfs file.

ARM implementation

We already standardise on U-Boot, for ARM machines. It's debateable whether Linuxboot is even desirable here, U-Boot is quite competent, but the SPL mode in U-Boot could be used to provide the Linux payload setup, OR:

See: uefistub

Although currently only under review, not yet merged anywhere, uefistub seems like a useful way to provide just the most minimal UEFI implementation, required on Linux distros, but all it does it then boot a Linux payload. This is probably what should be used, on ARM platforms, instead of U-Boot, if Linux is to be provided in flash, but the uefistub will use a lot less space than U-Boot. That being said, uefistub does not seem to provide a complete, or even fully correct UEFI implementation.

(then again, linux on bare metal providing kexec as main bootloader method is also quite non-standard, at least on x86 and ARM).

Disable Libgfxinit on DGPU setups

On machines where a discrete GPU is used, and no Intel GPU is present, but there are other variants where an Intel GPU is present, it is possible to provide a ROM image where:

Libgfxinit is enabled, for Intel graphics
SeaBIOS payload starts first, and can execute VGA ROMs from graphics cards
If a graphics card works, then that VGA ROM provides initialisation

When a dGPU is used, this can cause problems. For example, VGA-based mode setting doesn't work properly on some machines, for some reason. For example, on the Nvidia variants of Dell Latitude E6400, no Intel graphics exists. For some reason, enabling libgfxinit makes nomodeset no longer work, and VGA modes in various bootloaders e.g. syslinux/grub no longer work - whereas enabling just the SeaBIOS payload to load a VGA ROM, without loading libgfxinit, works reliable.

Look at lbmk build system documentation to know the difference between libgfxinit/normal configs. Basically, we only enable libgfxinit when available but we provide SeaBIOS as the default payload. If a graphics card is used, SeaBIOS scans the VGA ROM from it or one can be provided in CBFS.

We should keep doing what we're doing, but also provide configurations where only the VGA ROM is used, on setups that use a discrete GPU. Libreboot's preference is to use the native initialisation, but sometimes the VGA ROM has be to be used instead.

Seek QUBES endorsement

Libreboot is compatible with Qubes, on several supported mainboards. This could be audited, to provide a complete list. Qubes has a page on their website which lists compatible devices.

It would be a nice way to promote the Libreboot project, and promote Qubes at the same time, which is an excellent project. We could host a page specifically for it, saying what works on our end, and basically copy that to their wiki.

GRUB VGA modes

VGA support is not universal in Libreboot. We typically rely on GRUB to start in console mode (GRUB_TERMINAL=console), which means GRUB won't change modes, it'll just use whatever mode we started in.

We do not currently modify GRUB's video handling, so some distro setups will try to use VGA modes, or some syslinux configs (that GRUB can parse) will, causing weird behaviour on many Libreboot systems.

TODO: modify GRUB to only have behaviour matching GRUB_TERMINAL=console. See: https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html

This will prevent the need for modification. In some cases, it is necessary to modify GRUB_TERMINAL in distro grub configs. The way Libreboot's GRUB menu works is, it scans for GRUB and Syslinux/Extlinux configs on the user's HDD/SSD, switching to the first one found.

Libreboot systematically scans for GRUB/Syslinux/Extlinux configs provided by the user's operating system, by scanning partitions. It can also scan encrypted partitions (asking for the user to type their LUKS passphrase).

However, Libreboot switches to the first one found. In some cases, a user may have multiple configurations.

TODO: Keep the current behaviour, for performance reasons, but offer a mode where instead a new menu appears, with menuentries generated, where each one just switches to one of the detected configurations.

This would enable Libreboot to work more seemlessly on dualboot setups, where it is currently assumed that the user would modify grub.cfg in the flash.

This pertains to the GRUB payload provided in the flash, by Libreboot. It is currently the preferred payload in Libreboot, at least for x86 machines.

Document flash write protection

IFD-based method

Already covered, but could be documented more prominently. Use ifdtool --lock libreboot.rom to lock the IFD.

This method is easily circumvented, by enabling the Flash Descriptor Override, which varies from trivial to physically difficult depending on the board.

On some platforms, such as the Dell Latitude E6400, this method is entirely useless; on the E6400, the EC firmware can be instructed to override the IFD settings, by enabling the Flash Descriptor Override (in fact, this is part of what the dell-flash-unlock utility does).

FLILL-based method

We already vaguely mention Intel Flash Descriptor settings ta enable write protection. This documentation should be expanded on.

See: https://opensecuritytraining.info/IntroBIOS_files/Day2_02_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20Flash%20Descriptor.pdf

Actually, look at that site in general:

Anyway:

Universal across all currently known IFD versions, the FLILL section can be used to define invalid opcodes when the flash is used, and this could be used to define write and/or erase opcodes. Up to 4 can be defined.

This could be used to complement existing flash-based write protection. Of particular interest is the fact that the FLILL config cannot be overridden. Setting HDA_SDO (newer platforms) or HDA_DOCK_EN (GPIO33) to enable Flash Descriptor Override, will not affect FLILL entries.

We could document this on the Libreboot website.

SMM write protection

system management mode can also be used, to implement flash write protection.

PR (Protected Range) registers

Differing per platform but defined by Intel datasheets, the Protected Range registers can be set, to enable flash write protection. Once written, these cannot be changed until a reboot. Anything can set them.

This is the preferred method and should be the default (enabled by default), because it can be done from GRUB. So, it could be provided on GRUB setups.

We could make it so that all menuentries in the default Libreboot GRUB menu enable this, when possible on a given mainboard. The GRUB shell would not enable it, and special menuentries that don't enable it could be provided (or an entirely separate GRUB config, e.g. grub_unprotected.cfg).

With the PRx-based method, the user can easily circumvent it when they want to update their firmware. Combined with a passphrase in GRUB, for menuentries and the shell, this would prevent an unauthorised user from updating the system; boot password alone cannot protect against malicious code in the user's operating system, but this method would require a boot password.

It could also be done earlier, in coreboot, but then there's no way to turn it off. Doing it from GRUB (or Linux, when a payload for that is added) seems wiser.

In practise, this should probably not be the default. Libreboot's current default is no write protection, though most Linux distros and BSDs enable protecting /dev/mem by default, that the user can turn off at boot time when they want to flash (e.g. cmdline option iomem=relaxed in Linux, or kern.securelevel=-1 in OpenBSD).

Chip-specific

Some flash chips support their own write protection scheme, covered in their datasheets, but this is usually unreliable or inconsistent. This method is not to be relied upon.

Layers!

Security is all about layers. When you want to lock down the flash, use every method available to you.

20 KiB Raw Blame History