Which of these FOSS boot firmwares is the most secure while still being usable/stable?
libreboot and osboot just are coreboot builds.
They are coreboot built with specific parameters for specific machines.
libreboot does not include any binary blobs.
osboot does contain binary blobs.
coreboot gives you the option when building to include blobs or not.
Which you can use will depend on what machine you have.
Since they are all coreboot it makes little sense to ask which is the
most secure, except that I find it hard to recommend anything that Leah
has had a hand in.
When I comment in the Forum or in the mailing lists I speak for myself.
It is for the X230 which is intel based. Is there an issue with the dev?
For a reasonable security, you should use osboot on x230. For perfect user freedom, you could use Libreboot. See also:
Also, the osboot website explains the differences quite well.
osboot allows cpu microcode updates only as compared with libreboot which does not; coreboot, as it pertains to the x230, it doesn’t give you an idea of which binary modules are compiled into the firmware image; is there any way to find this out?
You can use cbfstool to see the files in the rom, if the rom contains config you can extract it and see the configuration that was used to build the rom.
@unman I have read you saying so many times over many threads without reading actually why you say so.
For the matter of this thread: i agree that either libreboot/osboot/skulls/heads are all coreboot distributions, delivering different default configurations on which firmware images are built upon, which address different use cases and different threat models.
What does secure means is different for many prople. If you mean trustworthy, i would go for a platform that has the less binary blobs. If secure means being careless and being able to run crap without changijg your habits, microcode updates would be a requirement nowadays.
I wish we had a commonplace to address once and for all this debatable idea.
1 Like
What is privacy? There are no binary blobs able to a dev to remotely view or keylog the user input.
What is security? Everyday computing usage is relatively secure from malicious hacking which does
not originate from embedded backdoors in binary blobs.
libreboot has the most strict policy regarding blobs, e.g. none are allowed; heads is a way of re-ownership
of firmware after the device has been in transit and attestation of the firmware integrity so as to detect tampering of firmware or boot sector issues like rootkits.
libreboot does not allow cpu microcode updates, which are binary blobs from the CPU manufacturer
(who can say what these blobs consist of? If they are non-free, you cannot verify their integrity)
no binary blobs → privacy
security by way of compartmentalization → Qubes, Whonix
But Qubes repos also contain non-free software so… is qubes really “private”?
What you want is BOTH privacy (no blobs) and security (virtualization, containerization, Whonix)
Is there any platform out there that does all of this?
libreboot + free distro (PureOS for example) + Whonix
You make it sound like Libreboot is a serious option, it only runs on a tiny subset of laptops released around 2008. The hardware that supports the firmware is so old it’s useless to most people, and that doesn’t even touch on the issue with the massive gaping security hole that is the result of the missing microcode.
1 Like
are you saying these systems are non-functional without the binary microcode from the CPU vendor?
So CPU vulns would be unpatched; which is why you need microcode updates.
So osboot looks like a more feasible alternative to libreboot when combined with heads
Did you know that Leah is the developer behind the osboot? What’s the problem with the latter?
Of course I know that.
My problem is not with osboot, but with Leah herself.
Some of this comes from her business practices, in companies running
off, and promoted by libreboot.
She has a proven record of over promising, failing to deliver, using
customer monies for her own benefit, and being untrustworthy.
When restarting the business she used a collaborator and then dropped
them after they had made some investment in time and money.
That would be bad enough, but she treats libreboot (and osboot) as her
own personal fiefdom.
She exercised complete control over libreboot until the debacle with the
FSF, at which time she was forced to step aside. But she came back,
pushing out the people who had stepped in, and reasserting herself as
supreme leader.
Again bad, but open source is filled with unpleasant delusional
characters running projects.
She has a record of doxing and outing individuals and publishing
private information.
Where is the evidence for this? It’s easy to find reviews of her
business dealings. For the rest you only had to look at r/libreboot on
Reddit - strangely, any critical threads have been removed, but you can
still find them. Did I say that Leah is the mod of /r/libreboot?
As for the projects, they only make sense if you trust the people behind
them. I don’t trust Leah.
At one time there was a release that could not be built from the claimed
source. Why? Who knows. Perhaps that was during one of her episodes.
All this is, of course, entirely my own opinion, based on dealing with
Leah, and her track record of dealing with others and with the
libreboot project. There is ample evidence to support my view.
This is why I find it hard to recommend anything that Leah
has had a hand in.
When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
microcode updates is not a thing on all platforms, for example, there is no microcode updates possible on Power9 cpus.
Microcode updates didn’t always existed on x86 either.
Microcode updates were created for a world where cpus were created faster, and where instructions sets were known to be bogus in some corner cases in past series, meant to have cpus being fixed after manufacture.
Speculative bugs were a first case where microcode updates were needed for security.
On older platforms (xx00, gm45 based platfroms, touching all libreboot Intel supported platforms) require microcode updates to benefit virtualization. I was lucky to have in my hands, once, a platform a reported myself to Leah, that had the microcode version recent to be able to have vt-x (virtualization) enabled and functional to have Qubes 3.1 (if i recall well) functional on a x200. But vt-d2 (again, see other threads) doesn’t exist on gm45 basef platfroms. This means there is no sys-net/sys-usb nor pci passthrough possible to offer hardware isolation on those platforms even if you are lucky to have latext cpu version with microcode under a x200, and you wont have Q4.1 supported on gm45. Even if using osboot with microcode updates on gm45, you wont have those old laptops offer vt-d2 (interrupt remapping requirement).
Microcode updates on newer platforms were requirement to fix cpu related vulnerabilities. Without them, retpoline and a lot of other kernel/xen fixes apply mitigation, where user need to be more conscious of the inherent vulnerabilities of the platforms they are choosing. Newer cpus come with newer instructions capabilities, coming also with new vulnerabilities, some of which older platforms not having that instruction capability won’t expose new attack surface.
Get home message on libreboot: political stance gor librr software. Microcode exist on die. Microcode updates can be applied by firmware or OS. Some capabilities need to be enabled in firmware. If not activated by firmware, those most of the time cannot be enabled by OS. Consequently, if virtualization is not enabled/supported in firmware, OS wont be able to use it.
Coreboot is shared initialization base for Heads/libreboot/osboot/skulls coreboot distributions. Those have different coreboot configurations, different blobs policies for inclusion. They have different payloads and apply different “security policies”.
As of today, it is considered " insecure" to not deploy microcode updates if they are available. Again, im nit saying that on a philosophical level, those microcode updates should be blobs; ideally they should be open source code and auditable, but I do not think this is a debate, but more of a problem and consequence of the industry.
For Power9, the solution, again, to spectre/meltdown was to release a new CPU (version 2) for customers to buy: there is no microcode update capability for that processor. On that level, microcode update woukdbyave been desirable since auditable. But since there is no capability, there was no possibility. Is that better? Is that more secure?
Microcode is code applied and executed by the CPU. That being upgradeable or not doesn’t remove the fact that it exists. The problem is for knowledgeable people in that low level area to be able to read the code, review the code and propose patches on that code. If that code is not available, the problem here is to trust those microcode. Being there, executed on die, or applied as a patch (diff) on top of what would normally be executed, is not really a problem, unless there is vulnerabilities in the way the signature validation of those microcode updates are verified prior of being applied and ran. On the way and by whom they can be applied.
Those microcode updates are applied either early, by the firmware (in stock bios updates) or through OS updates (Qubes apply them as well if existing for the platform).
So here we are on the debate if I understand well: should available updates be deployed if existing? My opinion is that they should be. The firmware should apply them ifnthey are available, otherwise leading to now known vulnerabilities.
But yet again, all of those should not be mixed and judged with a binary mindset. No, i’m not saying blobs are a good thing. But yet again, the microcode on die is a blob, updated or not. Microcode updates exist to fix what was discovered to be bad logic on what is otherwise printed on cpu die. So why would we not update it?
For example on kgep-d16: not applying microcode updates will result again on virtualization issues on some cpu versions. Not including microcode updates in firmware means a lower number of CPUs versions can be supported from a single Heads board configuration. Board fike specifies which CPU version is supported otherwise leading to problems. Problems that were fixed…through microcode updates.
The point here is dual: not applying cpu microcode updates for platforms that have them, in 2022, is a security hazard. The trust that we can have in blobs, whatever they are, is to be considered consciously, and is a never ending debate on which all would agree. There is nothing wrong with blobs as a delivery option. But those blobs should be accompanied with source code that one can audit if desired. If a blob needs to be delivered securely, and be signed to be authenticated prior of being loaded, then ideally, that blob should be possible to be signed by the user, not just intel/amd/arm whoever. The blob should be reproducible, outside of its signing. It should not be encrypted either, compressed I understand and is desirable.
Anyway. I think microcode upgrades is a good concept. The delivery system is also good. Packaging and application system is also good. Absence of source code to audit what they do is wrong, encryption of those blobs is wrong, unique signature from single entity (Intel) and consequent programmed obsolescence as seen on xx20/xx30 ivy/sandy bridge is wrong.
2 Likes
Concepts mixed here again.
Heads/skulls/libreboot/osboot are different coreboot build systems (distributions), aimed at producing ROM images based on different coreboot configurations (different features, different payloads, different mandates and goals).
Depending on the platform, yes, osboot would be a feasible alternative to libreboot if aimed at virtualization, and Qubes, if supported. As said at multiple places if we are talking about a x200, you won’t get far and get more secure by doing so. osboot will give you vt-x (virtualization) thanks to virtualization support from microcode update. But that wont give you proper vt-d2 (interrupt remapping). That won’t give you more then 8gb of ram.
Platforms supported by osboot but not heads means that blobs redistributions has been resolved under osboot for those platfoms where support has not been made in heads. Here we are talking about the t440p next as an interesting missing platform supported under Heads.
Osboot reused my idea of downloading firmware images directly from Lenovo or other places (chromeos), extract content (ME, vbios files for dGPU support etc) and deactivate and neuter ME in the build system itself, while distributing the Intel Firmware Descriptor (not really a blob but a firmware descriptor about region sizes and protection : IFD) effectively matching reduced ME regions and expended BIOS region. If not done, then the BIOS region is limited to what was defined under IFD initially. For older platfroms where ME can be neutered, we talk about a BIOS region that can be increased from 7.5mb to 11.5mb (xx30), permitting to pack a lot of useful tools in the BIOS.
osboot also distributes the GBE blob(generated, not really a blob but a configuration data. No execution code there. GBE generator is upstreamed code under coreboot), and created nvramutil to modify mac address and generate them.
Anyway, I appreciate osboot accomplished work and changing of stance and merging of libreboot and osboot. I think that project’s fondamentals are great. On my perspective, they upstreamed a bunch of needed work, and the collaboration I witness from Leah and osboot people is a good thing. I cannot talk personally about minifree sold products etc, and also witnessed a lot of drama from Leah/FSF. But on a contribution level, I have witnessed a lot of good stuff coming from libreboot and now osboot and without Leah, open source and freedom respecting platforms would not be at the same place we are today. We would not have the kgpe-d16 supportrd under coreboot up until 4.11 and the challenges of the status quo happening on the blob level. More work is needed there.
At the end, Heads will need to integrate the blobs download/neutering scripts for t440p. Include and add a mrc downloader script to download MRC blob from chromeos builds for pepper platform, and borrow their coreboot configuration and customize it. Replicate/customize ME scripts and add support for the t440p.
Osboot recently reused the “maximized board” concept that was brought by myself to Heads, permitting to dodge the legal “blob redistribution” limitation of current blobs license (or lack thereof). And have whole, valid and complete ROMs to flash both internally and externally, permitting to maximize available BIOS region space and use it for open source tools to have a proper recovery shell environement under Heads and guarantee ME is neutered by having freed space made available to future proof platforms for future addition of features (which require space and otherwise neverending optimization for size, hacking modules features and depending on smaller libraries then ideal (ex: mbetls instead of openssl library).
Those osboot/skulls/heads projects are different. Heads is a linux payload to coreboot (simplest description). But one cannot just build any linux payload and ask coreboot to boot it. Using linux as a coreboot payload ideally depends on linux to use its drivers to drive the system outside of the hardware initialization done by coreboot.
Basically, for Heads, a board configuration is a configuration including list of modules to be built and included (cryptsetup, gpg2 toolstack, fbwhiptail, lvm busybox, kexec, etc), a linux kernel configuration, coreboot configuration and tweaks to call linux from coreboot with the proper kernel options, and the configuration telling needed quirks to be applied when kexec’ing from Heads linux to the OS. All of that glue is tightly linked to hardware, drivers and final Operating System to be booted.
Osboot/libreboot/skulls are basically using Seabios+grubs as coreboot payload, delegating graphic initialization and bootloader logic, limiting feature enhancements to modifying those projects instead of using scripts/adding tools into linux initrd (Heads) to apply security policy prior of booting the system.
Once again, libreboot/osboot, Skulls, Heads and 1vyrain all have different goals and use cases.
No, Heads cannot be used as a generic payload and just dumped into osboot. That board will need to be included under Heads to function properly with Heads, and will need to be tested and maintained.
1 Like
I personally work under the assumption that these unauthorized updates have government backdoors in them. Big tech is going 1984 at full steam. I’m glad I still have a bunch of old computers
Apparently the binary cpu microcode updates are not significant enough to warrant concerns regarding
security anyways.
“In reality, the microcode is a series of hot patches to the instruction decode logic, which is largely part of a fixed function execution pipeline. In other words, you can’t microcode update a CPU to add or substantially change capabilities.” (the FSF’s relationship with firmware is harmful to free software users | Ariadne's Space)
A bigger concern may not be microcode updates, but code for things like memory controllers, embedded controllers, proprietary networking drivers, etc.
IMHO networking drivers are a much bigger risk after reading that article.
1 Like
I think we need the Qubes community to identify and classify the highest risk firmware components
in terms of privacy (binary blobs) and security (preventing a hack) of most systems. Some systems
have hardware components that others don’t and this creates a complex problem because you need to list all the firmware and drivers necessary fro this hardware to run. The first step is to list all the most common hardware necessary for a laptop, desktop, server system and the associated firmware. Then you can list them based on risk (privacy,security). CPU microcode updates don’t seem like they are that high on the risk list because they are actually increasing the security aspect even if they are blobs
right? Can those blobs really compromise the privacy of a system anyways? Networking hardware and
drivers are a much higher risk component anyways (higher up in the threat list).
1 Like