New changes in Libreboot

25 respostas [Última entrada]
gimpuedit
Desconectado
Joined: 10/14/2021

Libreboot is going to have some changes, my question is, with this new update Libreboot machines will continue to be totally free or not? Also, the new laptops that are going to be supported are going to be fully free (ThinkPad X230 and T440p)?

Here is the info:
https://libreboot.org/news/merge.html

jxself
Desconectado
Joined: 09/13/2010

It is, at present, impossible to make newer Intel & AMD machines be as free as the older libreboot machines. This used to be included in the libreboot FAQ; archive at
https://web.archive.org/web/20220619223000/https://libreboot.org/faq.html#intel

This seems to be changed in the current FAQ now because those machines are no longer "unsupported." The only way to make such a change from unsupported status to supported status, at present, is with the addition of binary blobs which in my view is a step backward for software freedom. Binary blobs can also be applied to the older libreboot hardware too (CPU microcode updates, and etc.)

Let's all have a moment of silence for the loss of the freedom-oriented libreboot.

WizardHemp
Desconectado
Joined: 11/28/2021

It is disappointing that they have started allowing blobs.

https://libreboot.org/news/policy.html
The policy document says that they will used the libre versions whenever possible.

But it also says
>An exception is made for CPU microcode updates: they are permitted, and in fact required as per libreboot policy.
It says that blobs are fully allowed if they are cpu microcode updates, I assume that this means that the later versions of libreboot will have cpu microcode blobs in them (even for the old laptops that were previously ryf compliant)

jxself
Desconectado
Joined: 09/13/2010

"It says that blobs are fully allowed if they are cpu microcode updates, I assume that this means that the later versions of libreboot will have cpu microcode blobs in them (even for the old laptops that were previously ryf compliant)"

That is my assumption as well.

Avron
Desconectado
Joined: 08/18/2020

With Libreboot 20220710 on X200 and Trisquel 10, I am sometimes having problems:
- from start, the boot remains stuck with the deer picture and "loading trisquel" on the right. I remember having left it here and that I finally saw the screen for the cryptsetup password, entered it, then it took ages before getting a login screen
- when rebooting, there is immediately a lot of error messages saying disks are not found, any tentative to boot without power off results in the same, after power off the problem does not repeat (the problem *never* happens at first boot)

I reported this on #libreboot on IRC, I was advised to make a but report for libreboot and for trisquel, and to build libreboot from latest source.

However, I remember reading that previously, libreboot had undone changes in coreboot that were causing issues with the non-modified microcode. So I guess that this will load the microcode updates.

Therefore, I am not sure what to do on my X200 now. I am considering re-flashing the 2016 version which did not show such issues.

PublicLewdness
Desconectado
Joined: 03/15/2020

My only real disappointment is that the main difference between Libreboot and Coreboot was the fact that if you wanted to run near blobless in the BIOS you could and if you wanted newer hardware support you could use a Coreboot system, now there is no difference from a blob standpoint.

That being said I am happy to see more ARM support.I will also take this new Libreboot over a fully closed BIOS.

jxself
Desconectado
Joined: 09/13/2010

Yes, I kinda don't see the point of having a separate project from coreboot in this case, other than it makes pre-compiled binaries for easy installation. But that's something the coreboot people could also do, if they wanted.

Jorah Dawson
Desconectado
Joined: 12/13/2020

Oh, I was about to install the new version and I've just read this...

My T400 with T9900 CPU and 8GB of RAM is still powerful enough but, in the future?
What alternatives do we have?

This is so gloomy...

prospero
Desconectado
Joined: 05/20/2022

I dare to wish to try to cheer you up: there are other options, and they keep coming. Someone recently mentioned that both PINE64 and MNT had made their debut in the fsf giving guide this year, in the "Promising Communities & Companies" section. This only confirms that the most viable path is to use hardware that has been designed to run with free software. This does not sound like gloomy news to me, more like a prediction that proved correct:

"Some day, free-design digital hardware may be the only platform that permits running a free system at all. Let us aim to have the necessary free digital designs before then, and hope that we have the means to fabricate them cheaply enough for all users." -- Richard Stallman

thispath11
Desconectado
Joined: 10/18/2022

Well, the brands you mentioned are indeed in the "Promising Communities & Companies" section, but this actually means they are not yet as free as what we hope the Libreboot firmware to be. At least I doubt if there is any LTE modem that works in the free world, for instance. Of course it is nice that these companies are trying to make their laptops and smartphones as free as possible, but in my opinion they are no "alternatives" to Libreboot if we are to be "purists". I'm rather pleased that Libreboot keeps improving to become a competitive alternative to proprietary firmwares.

Vikings_thum
Desconectado
Joined: 04/04/2017

Those old x86 Thinkpad and AMD boards always have been and still are an temporary solution until someone makes something better™.
Since you were looking for an alternative, Power 9 machines from RaptorCS are currently what works best w/o blobs if you have a budget.

Otherwise you need to be willing to make compromises, the T400 is no exception.

thispath11
Desconectado
Joined: 10/18/2022

In my personal opinion the change in Libreboot is not really anything we should be disappointed with. I suggest reading this section (or maybe the whole page) thoroughly:

https://libreboot.org/news/policy.html#problems-with-fsdg

The fact in this section is quite surprising (as well as disappointing) to me, but it unfortunately is true. To convince yourself, take a look at the simple example of Wi-Fi cards, e.g. this product endorsed by FSF:

https://shop.libiquity.com/product/wifri-nd2h

The product description says "The firmware is part of the hardware, stored within the chipset and modifiable by no one, including the developer."
Seriously? Let me go bold, all the "free" Atheros Wi-Fi chipsets except
- AR9271 (usually small USB-type adapters, only 2.4GHz)
- AR9280 (mini PCIe type, both 2.4 and 5GHz)
- AR9287 (mini PCIe type, only 2.4GHz)
have NONFREE firmwares deeply hidden inside them. If anything else (just like the product above) is endorsed by the FSF, it's either a "mistake" or a complete ignorance.
If you are using any Wi-Fi card other than the three mentioned above, it is probably running a nonfree firmware even if it works with Trisquel or any other FSF-endorsed distro - the only difference is whether the nonfree firmware is "hidden" somewhere deep inside the hardware that you believe is "free" or in your /lib/firmware directory (which typically happens when you enable the nonfree repo on Debian).

So, in the same sense, my point is that allowing microcode update neither increases nor harms your freedom, as long as you are using any modern CPU from Intel or AMD. You are already not as free as you hope or believe. Even the Core 2 series which the old Libreboot have supported have nonfree microcode "baked" on their ROM which are usually buggy and vulnerable. For example, try

$ sudo spectre-meltdown-checker --explain

and you should see "a lot" of warnings. This might not be a serious threat for a single-user laptop, but suppose you are maintaining a multi-user machine or a server. I don't see any point of sticking to a buggier and more vulnerable nonfree microcode and believing it is totally free. I do occasionally update the proprietary Lenovo firmware on my laptop, or mine would also be vulnerable to the flaws that were found already 5 years ago, as the mitigation is (of course) not provided by Trisquel.
I'm rather happy that the Libreboot developers are working really hard to keep the project going. I hope mine gets supported as well someday.

Avron
Desconectado
Joined: 08/18/2020

[from the page you linked] Excluding firmware blobs in the linux kernel is bad. Proprietary firmware is also bad. Including them is a wiser choice, if strong education is also provided about why they are bad (less freedom). If you expose them to the user, and tell them about it, there is greater incentive (by simple reminder of their existence) to reverse engineer and replace them.

Who is doing the "strong education"? The FSF, not Debian. With Debian, people are encouraged to use the non-free firmware and consider reverse engineering as a waste of time, and the whole reasoning here is flawed. Perhaps Debian users will even eventually think it is no problem to use any non-free software that is included in Debian, not only firmware.

> I don't see any point of sticking to a buggier and more vulnerable nonfree microcode and believing it is totally free.

How do you know the microcode update is not introducing an undesirable feature making it actually even more vulnerable? Any non-free update of it could actually make it worse while spectre and meltdown are not an issue for a single user machine running only free software.

I am a lot more concerned by what is explained at https://libreboot.org/faq.html#hddssd-firmware This page is very good and it is highly unfortunate that this is now polluted by flawed reasonings on microcode and on proprietary firmware updates.

jxself
Desconectado
Joined: 09/13/2010

This seems to be repeating things based on the notion that anything that does anything must have a software in it somewhere. In the cases of the cards mentioned they're all hardware circuits. The work's done on the host, not the device. Those cards don't even contain a processor to be *able* to run a firmware in the first place, regardless of whether "burned in" or uploaded from the kernel. This pokes holes in the arguments I've seen made that *every* device has a firmware and, if the kernel isn't uploading it, then the device is running its own copy somehow "burned" in to the device. There's no processor there for those devices to be able to execute a firmware.

It seems an interesting worldview. That there's software everywhere; nothing can ever be hardware circuits. Like this telephone:
https://commons.wikimedia.org/wiki/File:AT%26T_push_button_telephone_western_electric_model_2500_dmg_black.jpg
Where's the software in this? :)
Or these old computers: https://en.wikipedia.org/wiki/ENIAC#/media/File:ENIAC_Penn1.jpg etc. There's even a video of someone taking one of those phones apart:
https://yewtu.be/watch?v=RWbONnfYyzU
There's no software in there. :)

It's not equivalent to compare these to the microcode running on the host CPU. They are not the same.

Avron
Desconectado
Joined: 08/18/2020

In the cases of the cards mentioned they're all hardware circuits.

The post was saying that cards *other than the ones mentioned* have firmware baked in.

Is that wrong? What about AR9285 for instance?

In general, I would appreciate some education on how to see, for a given wifi card, whether the kernel runs everything (no processor in the card) or whether another processor is running something, and whether the kernel or something else is updating the firmware in case the card has a processor.

jxself
Desconectado
Joined: 09/13/2010

An interesting comparison can be done with regard to https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers which is where you'll find the comment about the lack of a CPU for ath5k and ath9k. Within the context of the kernel it's possible to check for the request_firmware calls. You will find those in drivers/net/wireless/ath/ath9k but those are in there for the ath9K_htc firmware, which are USB devices, and for which we have a free firmware to use: https://github.com/qca/open-ath9k-htc-firmware

prospero
Desconectado
Joined: 05/20/2022

> The post was saying that cards *other than the ones mentioned* have firmware baked in.

That was simply untrue. The correct summary is: "Atheros ath5k/ath9k doesn't require firmware. ath9k-htc requires firmware but there is free/libre firmware. Anything else require non-free firmware, although most of them do have free/libre drivers." Courtesy of nadebula.1984.

https://trisquel.info/en/forum/broadcom-wifi-trisquel-etiona#comment-159365

andyprough
Conectado
Joined: 02/12/2015

>"Courtesy of nadebula.1984."

The problem with the forum these days is the alarming lack of principled communists. We should have a required minimum number, and a certain number should be required to be Maoists.

prospero
Desconectado
Joined: 05/20/2022

Agreed. We also need less dissenting voices. Dissent should be limited to one or two posts per thread, once a month, in leap years. Sentences like "this is simply untrue" should be forbidden.

andyprough
Conectado
Joined: 02/12/2015

>"Agreed. We also need less dissenting voices."

The beatings will continue until morale improves.

thispath11
Desconectado
Joined: 10/18/2022

> The post was saying that cards *other than the ones mentioned* have firmware baked in.

You're right, I meant *other than the ones mentioned*.

> What about AR9285 for instance?

According to this page:
https://wikidevi.wi-cat.ru/Atheros#AR9200.2FAR9500_series
AR9285 seems to correspond to AR5B95 (click the link 'HB95/XB95'), which is exactly the one in the page I mentioned before:
https://libreboot.org/news/policy.html#problems-with-fsdg

But I get jxself's and prospero's point too. So I'm a bit confused, is the example demonstrated on the Libreboot website wrong?
I already knew about the Wikipedia page prospero mentioned, but I thought the information on the page might be incorrect when I first wrote on this thread.

By the way, Intel processors do have microcode baked on a ROM:
https://web.archive.org/web/20091221182054/https://www.ele.uva.es/~jesman/BigSeti/ftp/Cajon_Desastre/MPR/111204.pdf
(See the section 'Patches Stored in BIOS', I found this article from the Wikipedia page https://en.wikipedia.org/wiki/Intel_Microcode)
The article was from around the time of the P6 architecture, so I assume the same applies to the 'FSF endorsed' Core 2 processors too.
So my point is that the original microcode is not something we can fully trust either, in the same way that you cannot trust the nonfree microcode update included in BIOS or the Linux kernel. It is completely reasonable that you refuse such nonfree microcode update, but what the Libreboot developers are saying is that the original microcode is not free either (and so is my personal opinion) and people would not be aware of this unless this issue is clearly addressed.

jxself
Desconectado
Joined: 09/13/2010

ARM has their micro-instructions baked into the instruction decoder instead. See https://developer.arm.com/documentation/uan0015/b/ which talks about, even though there isn't a ROM to store each micro-instruction, individual instructions are still decoded into smaller micro-operations (μops) nevertheless. That's very much like how a microcoded processor works too. We can imagine Intel has a "source" for what goes into the ROM. We can also think of the ARM HDL as being the "source" in the ARM world and that instead of putting each micro-operation in a ROM, they just go into the instruction decoder instead, which can be altered by the manufacturer as desired to alter how the instructions get decoded into micro-operations (μops) and in doing so, alter the CPU as they desire to fix bugs or whatever - Just like Intel can. I'll ask and answer: Why does putting the micro-operations (μops) into a ROM vs an instruction decoder make things any different? Both have "source" that can be edited by the manufacturer to change as desired but, for the end user, they're both just as unchangeable. At least, not without building a new CPU - there's no real difference there. In order to be logically consistent it shouldn't matter where the micro-instructions get baked in. Micro-instructions exist in both (see PDF) and to be consistent they're either both acceptable or neither are.

Avron
Desconectado
Joined: 08/18/2020

I feel bad for how these shops are absolutely price gouging people $500 dollars or more for very old hardware. Freedom should be accessible to all.

Sure, not only freedom, a decent living as well, but I don't expect this to happen in a private profit driven society.

jxself
Desconectado
Joined: 09/13/2010

For sure. We can't expect people that are doing this to work for free or at (or just above) the poverty level for their part of the world. Every business will have fixed costs to remain operational and there isn't exactly a lot of volume in these businesses of 100% free software to break that up over. The notion of other hardware being cheaper seems to be based on comparing it against companies doing mass production which lets the per-unit price be smaller or in other cases where it's not being used to support someone's salary, like someone on eBay that's doing it to clear out their attic/basement. If someone else thinks they can do this job at a lower price point they're welcome to make the attempt and show everyone else how it's done. :)

prospero
Desconectado
Joined: 05/20/2022

Do you mean it is either the socialist revolution or the end of software freedom?

Avron
Desconectado
Joined: 08/18/2020

Sorry for the off topic but since we were talking about prices, I find the decent living for all somehow more critical than software freedom for all, although I support both. With respect to your comment, I am afraid it could be socialist revolution or massive destruction and death.