Latest "stable" Libreboot is very slow to boot Trisquel on my X200
I previously had the version 20160907. I used to have the "full disk encryption" option with Trisquel 9 but I think at some point I reinstalled Trisquel 10 with unencrypted boot.
In my recollection, between the boot menu and getting the graphical screen with the cryptsetup passphrase box, it took less than 10s.
With the "stable" 20220710 version, the time it takes is much longer. I just tried 3 times and checked the exact timing. When I select the entry to load encrypted system, I see "Booting Trisquel" and the deer for quite a long time:
- First attempt: 50s then I see the cryptesetup passphrase box
- Second attempt: 120s then I see the graphical screen with the Trisquel fading and coming back. After 40s more, I see the cryptsetup passphrase box.
- Third attempt: 75s then I see the cryptsetup passphrase box
Is anyone using that version of Libreboot? I am considering to flash the 20160907 version again, it really looked more reliable.
Hey!
I think this problem stems from the coreboot used in the stabilization of libreboot. This was corrected in the test release 20221214. Then go ahead.
https://www.mirrorservice.org/sites/libreboot.org/release/testing/20221214/
Newer versions of libreboot contain nonfree software.
While, you're not wrong, I'd like to clarify something for OP. The nonfree software included in Libreboot is CPU microcode, which is already hardbaked into the CPU. This just updates it. So, some of us, like me, don't really see a problem with it.
If you want to be more free, look into arm options like the RockPro64 with blobless uboot or the Samsung Chromebook Plus. Both have no microcode, no proprietary ec firmware, and no Intel ME neutered or otherwise. Probably the most libre options except for the Talos II or Blackbird, but those are out of many peoples budgets, and I believe the Power10 successors to Power9 will be proprietary, so arm and risc-v are looking to be the only options in the future.
jxself is correct though, Libreboot for x86 machines is nonfree now. But the microcode already in the CPU's in already nonfree, and updating it protects against vulnerabilities like spectre. So really, even with the new included nonfree microcode, a Librebooted ThinkPad is no less free than before. Correct me if I'm wrong, I try not to spread misinformation purposely.
Yes I've seen this argument that software which is required to be installed and loaded by users is not any different from that which comes preloaded into the hardware before, and it's fallacious. The fallacy behind this reasoning is that since blobs are proprietary software, they do not serve the user, but rather the developer, leaving the user powerless over the device. While this is true, it is not the whole story. The difference between the two types of blobs lies in the amount of control the developer holds over the user.
In both cases the user is just as powerless but in the case of updates, the developer can arrange for updates to be pushed out (or convince the user to install it), and in doing so they have greater power and control than the user, which is where the control ought to be.
On the other hand, blobs that come preloaded into the hardware are technically and ethically equivalent to a circuit. Think about that sentence for a time to fully appreciate how they can be equivalent. Such things can only be replaced if the developer convinced the user to bring the device to a repair shop. This is a more costly and less likely option for developers to pursue.
In both cases, yes the user is powerless, but the developer gains additional control over the user as the device becomes more flexible with regard to updates. If the software were freedom-respecting, this flexibility would serve the user as they could modify the software themselves in whatever way they want. However, since we are talking about blobs, which by definition do not respect users' freedoms, this increased flexibility operates against the user's interests. In these it's important to reject that increase in flexibility and control on the side of the developer.
In essence, arguing to accept the updates is an argument that users should accept having no control and not mind when the developer's able to make changes (while the user themselves cannot), and thereby increase the developer's control over the devices, all in the name of better features. However, in these cases it's better to have a stalemate where no one get to update it, where it's preloaded and unchangeable than to bow down and accept the developer's unilateral control of upgradable device smarts. The first way we can do that is by refusing their control attempts, essentially "If I don't get to be in control, neither do you." Yes, in both cases the user is powerless but in one of the cases the developer retains their control over the user and in the other they're both powerless. They are not the same situation.
Closed-source security updates:
-Fix known vulnerabilities.
-*Might* add or improve backdoors. But then, there *might not be a backdoor*, or there *might be a backdoor from the beginning that will continue to be there anyway*.
Best thing is to use fully free machines. But if you are using a partially free machine such as the Thinkpad, you are in a dilemma when it comes to update the proprietary firmware blobs. Are you leaving known vulnerabilities unfixed because of the possible risks?
Not really a dilemma, and this whole post seems to miss the point I was making. Perhaps you disagree, but what I said can't be made wrong by argument of this type.
Are you leaving known vulnerabilities unfixed because of the possible risks?
As far as I am aware, the vunerabilities in question are Spectre and Meltdown. Having read https://www.fsfla.org/ikiwiki/blogs/lxo/pub/who-is-afraid-of-spectre-and-meltdown.en.html, since my computer is not a server shared between multiple users, the risk is only data being readable between processes while not using the interfaces for communication between processes, and these processes are anyway supposed to be doing what I want, so that does not seem to be an issue at all, while the update will cause performance loss that I certainly don't like.
So even from a practical perspective, I prefer not to have that kind of "security" patch.
What fully free machines are available? The ones I know that come closest are the Talos II, Talos Blackbird, the Asus C201, and RK3399 devices. These all seem more free than the ThinkPads anyway.
I heard about these microcode updates.
I also heard that they are supposed to improve "security" and reduce performance, the "security" enhancement being things against meldown or spectre, which look pretty irrelevant for a computer running only free software for a single user, so this is one more reason why I'd like not to have them.
Is 20160907 the last "good" version for an X200 without them? Or is there another one?
On the T400 I bought from minifree, it is osboot that was provided, so these updates are there unfortunately. However, as I have no way to do external flashing, my manual skills are very poor (I was very very hesitant to flash my X200, now I somehow regret it), and I don't know anyone skilled to changed that, I am living with it curently.
"Page Table Isolation (pti, previously known as KAISER 1) is a countermeasure against attacks on the shared user/kernel address space such as the “Meltdown” approach 2."
"Protection against side-channel attacks is important. But, this protection comes at a cost:"
https://www.kernel.org/doc/html/latest/x86/pti.html
"When two major vulnerabilities known as Meltdown and Spectre were disclosed by security researchers in early 2018, Firefox promptly added security mitigations to keep you safe. Going forward, however, it was clear that with the evolving techniques of malicious actors on the web, we needed to redesign Firefox to mitigate future variations of such vulnerabilities and to keep you safe when browsing the web!"
https://blog.mozilla.org/security/2021/05/18/introducing-site-isolation-in-firefox/
"Mitigating Side-Channel Attacks
At the beginning of 2018, researchers from Google's Project Zero disclosed a series of new attack techniques against speculative execution optimizations used by modern CPUs. Security researchers will continue to find new variations of these and other side-channel attacks. Such techniques have implications for products and services that execute third-party code, including Chrome and other browsers with support for features like JavaScript and WebAssembly.
The Chrome Security Team has written a document covering the variety of defense techniques available.
Protecting users with Site Isolation"
https://www.chromium.org/Home/chromium-security/ssca/
https://www.zdnet.com/article/linux-kernel-gets-another-option-to-disable-spectre-mitigations/
Libreboot is pushing proprietary blobs for all supported devices? Even those who work unarmed? For example, intel p8600, Penryn, in the T400?
Yes, the Libreboot ThinkPad's that use the Penryn CPU's include non-free CPU microcode in the newest releases of Libreboot.
Libreboot itself isn't nonfree, just the x86 machines. The arm ones they support, like the Chromebooks on their list, have no microcode, so they have no nonfree microcode to include in Libreboot.
"Known issues
Intel ME firmware missing in ROMs that need it
If you compile ROM images with lbmk directly, the build system automatically fetches ME images from the internet and neuters plus truncated them, using me_cleaner. This downloading is done to avoid distributing them directly in Libreboot, and they get scrubbed by the release build scripts.
To re-insert neutered/truncated ME into your image, look at the guide.
This applies to sandybridge, ivybridge and haswell Intel platforms, e.g. X220, T420, X230, T430, T440p. On older Intel platforms such as GM45+ICH9M (X200, T400, etc) the Intel ME image isn’t needed and Libreboot ships with ME-disabled configuration"
https://libreboot.org/news/libreboot20221214.html#intel-me-firmware-missing-in-roms-that-need-it
.
It is time to migrate to POWER ISA. But that is a long way, so I still use old x86 hardware.