I know these questions have been asked and answered in various places all over the internet, but for some reason half the answers I have found just contradict the other half and I just end up more confused than when I started.
I would really appreciate some clarification on these questions, and if the answers I have found below are correct or not…
They are:
What are the differences between a Librem laptop and a Libreboot laptop, in terms of privacy and security?
From what I understand after reading several very long flamewars, there are two differences:
First, the Librem has the ME “neutralized”, but not removed, while the libreboot laptops have it completely removed. This means the ME is still capable of executing code, but the code is removed before bootup. (edit: Not exactly. It’s not entirely removed in either system, since both require the ME to startup. In the Libreboot the code comes from the internal ROM on the chip, in the Librem it’s externally stored)
Second, the FSP is still present on the Librem but is not present on the Libreboot. I couldn’t find the FSP mentioned in the Coreboot wiki so I don’t know how important that is or what the FSP is used for. The only resource I have found describing what the FSP does comes from the Intel website. (Edit: Now that the ME is disabled, the FSP is next)
Third, the Librem has an IOMMU (edit #3: incorrect, does not have an IOMMU… Thank you kakaroto)
I don’t know if the VBIOS or EC are freed or not. I would assume the EC at least would be rather easy, because it’s just a microcontroller that Purism would need to program from scratch anyway, but I could be mistaken. (edit: VBIOS is freed for Broadwell-era CPUs, Skylake is still in-progress. EC non-free but has low security/privacy implications)
Why isn’t the Librem RYF-certified?
Never seen this explained anywhere, but I’m guessing it’s because of the FSP, unless the VBIOS and EC are closed as well. (edit: The Librem probably won’t get certified in the near future at least because of the ME issue. Although the ME is currently both “neutralized” [meaning that about 85% of the code is removed] and “disabled” [meaning that the remaining code has the “HAP” flag set which causes it to deactivate itself], this doesn’t change the fact that the ME core still runs some binary blobs at bootup)
Why isn’t the Librem Qubes-certified?
I think it’s because Qubes demanded excessive royalties. (edit: Yes, sadly. Also Qubes 4.x requires the IOMMU to be enabled, but this can be done by the end-user on a Librem)
Although I have read The Purism FAQ, it doesn’t give any overview of the differences between Purism and your “competitors” in the privacy market. I’ve personally been looking for a long time to find a private/secure laptop, and I haven’t bought one yet simply because I am still trying to find an unbiased list of differences between the options. For example, what are the remaining binaries in the Librem? What do they do?
The Freedom Roadmap says in one spot that you still need to liberate the VBIOS, FSPandEC, but in another spot says "Purism laptops are completely free from the BIOS (see the history of our coreboot involvement) to the bootloader through the kernel(with no mystery code, binary blobs, or firmware blobs),including the operating system and all software." Which is it?
So, I apologize for asking these questions yet again, as I’m sure the Purism staff is tired of them… But then, could you maybe add these sort of questions to your FAQ?
I know I’m not the only one with these questions, and I’m sure there are others continually discovering the different privacy options available who would appreciate such a comparison.
Thank you again Purism for your dedication to privacy and security, and Happy Thanksgiving if you happen to be in the US!
I think it’s because Qubes demanded excessive royalties.
This was mentioned in older threads, yes. Another technical reason would be that the current custom coreboot version for Librems has IOMMU/VT-d not enabled, so you can’t properly run the upcoming Qubes 4.0 on them anyway.
You cannot compare a laptop and a software…
Libreboot only supports the pre-2008 Intel CPUs that did not have ME and FSP.
Librem laptops use coreboot (which contains binary blobs) and Purism spends significant time to disable and remove as much of these blobs as possible.
Currently, some of the libreboot people seem to flame Purism to even dare selling Laptops with some blobs still left.
But I guess as soon as the last blob went away, due to the work that Purism and lots of others have invested, they will happily jump on the train and use current CPUs.
Except … those who currently make a business by selling old Thinkpads from 2007 (which didn’t have ME) might be sad
The Librem is not RYF certified because Pursim is not yet at the end of the road. See roadmap.
Also, read all the status updates linked there, if you really want to know what’s going on @kakaroto just started reverse-engineering the FSP, although the article is about how that works, it will not really help you if you’re not into assembler
So, I think it boils down to this: you can either buy a very old laptop with Libreboot and no blobs or a recent laptop with fewer and fewer blobs (hopefully no blobs soon). Both are not exactly cheap, but the Libream is up to date. Also, the one business model is a dead end (can’t stick to 2007 hardware forever) and the other actively shapes the future. You decide
I agree that Libreboot is a dead-end, both because of their old hardware and their terrible leadership…
…Though if I may make one small correction, AFAIK Libreboot laptops (2007-era thinkpads etc) do still have a ME by default, but it’s an earlier version that resides on the Northbridge instead of the CPU, and that isn’t necessary for boot-up, so they could delete it without adverse effects.
Also, are you saying the Librems have other blobs besides the FSP? That’s one of the things I wasn’t sure on in my original question. According to the roadmap, there’s 3 binary blobs remaining: the VBIOS, FSP and EC. Is that correct?
You got some excellent questions, so let me try to answer them to the best of my abilities …
A librem laptop is a recent hardware with a focus on privacy and security. It does that by giving you a system which works without requiring any binary blobs in the linux kernel, and it has hardware killswitches to allow you to disable wifi/bluetooth/camera/microphone. The libreboot laptops are old machines that are refurbished and have the ME removed, and run linux. I don’t know if they come with a webcam/microphone, but if they do, you can’t kill those by hardware, you could duct-tape the camera, but you can’t mute the microphone for example. If they don’t come with webcam/mic, then that’s one less feature they have… you get the idea.
The big difference in terms of software is that the libreboot comes with libreboot and librem comes with coreboot. Coreboot uses binary blobs to initialize the hardware, while libreboot doesn’t. That’s why libreboot is limited to pre-2008 (not sure exactly if it’s pre-2008 or pre-some-other-date) harware.
well, yes, and no. The ME being neutralized makes it really neutralized, it doesn’t have a kernel, it doesn’t have a network stack, it can’t do anything. Our latest releases actually come with a disabled ME, which is totally disabled and not running. The libreboot laptops have it ‘completely removed’ from the flash, yes, but the ME still runs some code from its own internal rom, so really, there’s not that much of a difference between the two, since both will run ‘some code’ at boot to initialize the hardware, then both will disable themselves (libreboot because it can’t find the rest of the firmware in the flash, and librem because it finds the HAP feature enabled which tells it to disable itself, shut down and stop running). If you read my blog post about the ME disablement you’ll see that there is always some code running from the ROM. Libreboot doesn’t mention this because it obviously goes against their marketing campaign that the ME is “completely removed”. The difference though is that the FSF can RYF certify a device if it has no externally-loaded binary blob, if the full ME firmware was stored inside the ME’s internal chip itself and it was running, it would still be RYF, but if you have 1KB of code loaded from an external chip (the flash), then you can’t RYF certify it anymore. So that’s the big difference for the ME, the code that it runs is not ‘externally loaded’ for the libreboot.
Yes, that’s because the pre-20xx hardware had the FSP reverse engineered already (or maybe there was documentation, things were simpler back then, etc…) and so coreboot/libreboot can initialize the hardware all by itself. At some point though, support is non existent and we need to use the FSP, which is “Firmware Support Package” which is just an intel-fancy-word to say “code to initialize the RAM and the PCH”.
You can see the mention of it in the Binary Situation page of coreboot, although in that page, it’s referred to as “Memory Reference Code” because it was called the MRC in coreboot for broadwell, then it became the full FSP image after skylake.
Yes, it does have an IOMMU, however, it’s not currently enabled, it just need to be enabled in coreboot, and that’s the thing we’re going to work on next. Older hardware simply do not have IOMMU support as far as I know.
The VBIOS isn’t freed yet, but there is work already for a native graphics init. However, I think the last I heard was that there was some bug that made it not work for skylake and they were still looking into it. So there is progress there, the VBIOS isn’t freed, but it should be easy to free it eventually, so just keep an eye out for that. As for the EC, it’s unfortunately not freed either. We looked into that rather quickly, but I think the task would not be a trivial one. The EC however doesn’t have much control over your system, I might be wrong here but as far as I know, it mostly manages the battery and fans.
See the Freedom Roadmap. For a device to be RYF certified, you need to have 100% free software on it. Due to the small portion of ME code remaining, as well as the FSP and VBIOS, the device can’t be RYF certified. I don’t know if the EC would count though. Either way, work is being done to move us forward on that roadmap, so eventually we hope to get RYF, but for now it’s not possible.
It used to be certified, then Qubes decided to change the deal we had with them and it was just not financially viable. I already explained some of the new costs involved in keeping the certification here if you’re interested int he details. But there are three things here :
Librem 13 v1 was Qubes 3.x certified
Librem 13 v2 never went through the Qubes 3.x certification, but there are no technical reasons for it not to work
Librem 13 v2 would not work with Qubes 4.x (which I’d like to remind everyone is not yet officially released) because it requires IOMMU to be enabled.
(Note that when I say “librem 13 v2” that also includes “Librem 13 v3”).
The libreboot page had a very anti-purism text in their FAQ which was full of false statements and was really bashing on purism for no good reason. It was eventually taken down after a long time, then I think a more subdued version was put back into their FAQ. I think that since the one-and-only project leader of libreboot is also the main person benefiting financially from the sale of the libreboot laptops, you need to be careful about such statements. I think that making a statement about competitors without it turning ugly, hurting someone’s feelings, or being accused of skewing the truth to our advantage, would just be too hard, so I think it’s just better to let people decide on their own or find answers elsewhere. The rest for a flamewar is too great.
That’s a mistake I’ve seen others make before. The statement says without the parenthesis says that “Purism laptops are completeely free from the BIOS to the bootloader through the kernel, including the operating system and all software”. Now, if you add the parenthesis, you realize that the “BIOS (see the history of our coreboot involvement)” is freed because it runs coreboot instead of a proprietary BIOS, and that the “kernel (with no mystery code, binary blobs or firmware blobs)” is the linux kernel with no binary blobs. The freed coreboot BIOS itself is not binary blob free, it’s the linux kernel that is binary blob free, so it’s important not to confuse the two.
Most machines nowadays that run linux require a lot of binary firmware for them to work. I think just for the wifi to work, we only found one wifi card that doesn’t require a binary firmware, so the fact that you can run a binary-free linux distribution on the machine and that every feature (other than bluetooth) works, is a great achievement/feature of the laptops in itself and that’s what the statement is making, not to be confused with the binary-freedom-status within coreboot itself.
Yep, pretty much a good conclusion, so I’ll just reuse your conclusion for my post as well, thanks!
Thanks so much for the in-depth answers! I totally understand that you want to distance yourself from making “official” comparisons, simply because of the drama that has occurred elsewhere.
I unfortunately hadn’t noticed before that your blog was where all the deblobbing updates were posted, I’m impressed by the transparency you have been providing! Please keep up the great work!!!
You’re welcome.
And it’s not that IOMMU is not “enabled anymore”, but rather that it never was enabled. Qubes 3.x did not require IOMMU. The IOMMU requirement is new in Qubes 4.x, which is why only Qubes 3.x works for us for now.
