'100% Free' GNU Boot Discovers They've Been Shipping Non-Free Code - Again (phoronix.com) 36
Libreboot is a distribution of coreboot "aimed at replacing the proprietary BIOS firmware contained by most computers."
So then what exactly is GNU Boot? Its home page explains... In November 2022, Libreboot began to include non-libre code. We have made repeated efforts to continue collaboration with those developers to help their version of Libreboot remain libre, but that was not successful. Now we've stepped forward to stand up for freedom, ours and that of the wider community, by maintaining our own version — a genuinely libre Libreboot, that after some hurdles gave birth to this project: GNU Boot.
But today, Phoronix writes: While priding itself on being "100% free", last December [GNU Boot] had to drop some motherboard support and CPU code after discovering they were shipping some files that are non-free by their free software standards. Today they announced another mistake in having inadvertently been shipping additional non-free code.
GNU Boot discovered an issue with non-free code affecting not only them but also some of the Linux distributions that pride themselves on being fully free software / 100% open-source. This latest snafu they say is "more problematic" than their prior non-free code discover due to impacting the free software Linux distributions too. The issue at hand though comes down to test data contained within the archive and that containing non-free code in the form of microcode, BIOS bits, and Intel Management Engine firmware.
"We also contacted Replicant..." according to the announcement, "a free Android distro that also ships vboot source code." And in addition, "We had to re-release all the affected tarballs." (Which at this point is three release candidates...)
So then what exactly is GNU Boot? Its home page explains... In November 2022, Libreboot began to include non-libre code. We have made repeated efforts to continue collaboration with those developers to help their version of Libreboot remain libre, but that was not successful. Now we've stepped forward to stand up for freedom, ours and that of the wider community, by maintaining our own version — a genuinely libre Libreboot, that after some hurdles gave birth to this project: GNU Boot.
But today, Phoronix writes: While priding itself on being "100% free", last December [GNU Boot] had to drop some motherboard support and CPU code after discovering they were shipping some files that are non-free by their free software standards. Today they announced another mistake in having inadvertently been shipping additional non-free code.
GNU Boot discovered an issue with non-free code affecting not only them but also some of the Linux distributions that pride themselves on being fully free software / 100% open-source. This latest snafu they say is "more problematic" than their prior non-free code discover due to impacting the free software Linux distributions too. The issue at hand though comes down to test data contained within the archive and that containing non-free code in the form of microcode, BIOS bits, and Intel Management Engine firmware.
"We also contacted Replicant..." according to the announcement, "a free Android distro that also ships vboot source code." And in addition, "We had to re-release all the affected tarballs." (Which at this point is three release candidates...)
meanwhile (Score:5, Informative)
your cpu is running "non free" microcode so what is the entire point here? you'd have to switch to risc-v to get a true open cpu.
Re: (Score:2)
Re:meanwhile (Score:5, Informative)
your cpu is running "non free" microcode so what is the entire point here? you'd have to switch to risc-v to get a true open cpu.
RISC-V is a spec. A RISC-V CPU is an implementation of that spec and there is nothing stopping that implementation using "non free" microcode. In a large CPU, there are many good reasons to incorporate microcode and I expect to see RISC-V with microcode become common.
Re: (Score:2)
In a large CPU, there are many good reasons to incorporate microcode and I expect to see RISC-V with microcode become common.
You mean "large CPUs" like the Intel 8086 [reenigne.org]?
I mean, it was quite a big component for it's time with it's 29000 transistors, but...
Re: (Score:2)
In a large CPU, there are many good reasons to incorporate microcode and I expect to see RISC-V with microcode become common.
You mean "large CPUs" like the Intel 8086 [reenigne.org]?
I mean, it was quite a big component for it's time with it's 29000 transistors, but...
The 8086 was a long time ago used microcode for different reasons. It had a limited transistor budget and microcode was an efficient way to implement lots of instructions. Obviously there were other options, and it wasn't long before transistor budgets increased to allow for microcode-less CPU architectures.
Today in chips with many more transistors, microcode affords the flexibility to respond to security issues and bugs and to provide support for all sorts of features (VM stuff, trapping, failover etc) wit
Re: meanwhile (Score:1)
Are there any free motherboard pcb designs our there?
Re: (Score:3)
Don’t know about motherboards but a lot of the cheap single board computers have published schematics.
Re:meanwhile (Score:4, Insightful)
Not necessarily RISC-V in particular, but practically speaking you're not going to be able to run 100% libre firmware unless you're also on 100% libre hardware.
Re: (Score:1)
Re: (Score:2, Insightful)
Re: (Score:1)
This random reddit user sounds 100% truthful.
Re: (Score:3)
It is 100% truthful that this is the case. Very few non x86 Windows machines can run anything except Windows.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Now it's certainly true that some early trusted platform designs would have locked out Linux and it wasn't by accident. However, those things never gained any traction. There just wasn't support for that anywhere. For the exact same reason that we aren't going to see 75% of US states vote to remove the second am
Re: (Score:3, Interesting)
Why on earth are people upvoting this???
We're not talking "free" as in "beer"; we're talking "free" as the product we purchase is not encumbered by closed software licenses!
Yes, x86 based CPUs are encumbered in technological corporate fuckery, but some of it is based to make laptops near impenetrable to entities that's not the owner!
Only ideological zealots (the unkempt neckbeards types like Richard Stallman) and the CCP want RISC-V based CPUs to be adopted by the laptop industry, to avoid the issues posed
Re: (Score:3)
This is typically what happens when fanaticism gets in the way of pragmatism. They did previous stuff like try to rip all of the "non-free" firmware/microcode out of the kernel, but without doing anything useful like reverse engineering it/providing open alternatives, just outright disabling functionality. If they want a real free design, then it needs to start at the HW and work its way up, anything else is just a bunch of clowns having a wank.
Re: (Score:3)
just outright disabling functionality
That was their only option.
Modern x86 CPUs with factory settings won't run for long without their proprietary bits. Replacing those bits with any code (FLOSS or not) cannot be done without the manufacturer blessing the code. (A.K.A. Signing the code.)
To be fair to the fanatics, even the disabling option is a fluke made by the CPU manufacturers. It was implemented because the US DOD wanted a high assurance mode where none of that crap would be running for the CPUs they bought themselves. So, the US DOD
Re: (Score:2)
That's if you want to use GNU Boot. GNU Boot has very limited compatibility.
Of course, if you don't mind non-free, you can use coreboot - GNU Boot is a fork of corebook minus the non-free bits. However, there's a bit of controversy since the coreboot devs decided they wanted to help GNU Boot out by moving it to an updated fork they called NewBoot, then libreboot after GNU boot dev
Boot (Score:1)
>"While priding itself on being "100% free", last December [GNU Boot] had to drop some motherboard support and CPU code after discovering they were shipping some files that are non-free"
So, essentially, "Gnu Boot" is free by being bootable-free :)
I like the idea, but I am not sure how it will be possible to replace AND maintain every little bit of what goes into the modern boot process.... IME, LOM, low-level drivers, CPU microcode, etc.
Big egos doe nto make for big skills (Score:2)
Accept that modern CPUs require non-free code and move on. Or make it a fundamental point and look like idiots.
Re: (Score:3)
Accept that modern CPUs require non-free code and move on. Or make it a fundamental point and look like idiots.
When there are no more computers free enough to boot Linux, some company will then offer a freely bootable competitor. An alternative would be government regulation requiring that manufacturers provide a freely-boot option for no cost. The trick at that point is the manufacturers right to warranty. They can say the computer has no warranty and is not fit for any purpose except (e.g. running Windows). So when their hardware fails, you have no recourse at all.
Computers that are not intended as general-purpose
Re: (Score:2)
That sounds good, but have you forgotten that the CPU you boot is very much non-free in almost all cases already?
They could always ... (Score:3)
Re: (Score:1)
Lol, nice
Surprised no tools to help with this. (Score:2)
Meaning a way to flag a set of code as under a certain license, then mark out the licenses you're willing to accept. Throw a build error if you try to link or combine with the wrong kind of code/tools.
This isn't something I care a huge deal about, and maybe the issue is getting 'everyone' to participate in the same process/method/system.
Re: (Score:3)
It's sometimes difficult to distinguish the original licenses and codebase. I've had "open source developers" edit a few lines and scrape off the original copyright notices in favor of their own, or entirely remove them when publishing their open source. And I've had to report them to their company's intellectual property lawyer, because I was being asked to add code to the fraudulently licensed codebase, to protect _myself_ from possible responsibility. That IP lawyer and I had several fascinating conversa