"100% Free" GNU Boot Discovers Again They Have Been Shipping Non-Free Code

[archkde]

ACPI is not part of UEFI, and neither is SMM. UEFI Runtime Services are not used to "load" the kernel, either.

ACPI tables and the SMM handler usually ship in the firmware blob that is the UEFI firmware (and actually the ACPI specification is handled by the UEFI forum for quite some time now, but that was not my point). While I have no idea of what "loading the kernel" entails to you, usual conceptions of this concept actually do rely on UEFI (more specifically, the kernel is already loaded in boot services using LoadImage, and loading the initrd may involve a custom boot services protocol too). And in any case, the statement you quoted ("the linux kernel will need UEFI only to provide the boot information") appears stronger to me since it doesn't refer to loading the kernel only, and guess what, Linux does rely on runtime services for several operations (like access to UEFI variables, the RTC, or shutting down the system).

[Almindor]

You are too vague about the "various factors". Let's de-mystify them, so that we can blame some of the parties involved:
- the blobs which initialize the AMD and Intel CPUs are signed by those companies. They refuse to provide other parties with signing keys. Alternatively, they could have instituted a program which would allow other parties to submit custom initialization routines for signing, but those companies continually refuse to do that
- the blobs which initialize the AMD and Intel CPUs are encrypted by those companies, so noone can analyze what those blobs do, so noone is able to replicate their functionality
- both companies refuse to publish essential documentation about the initialization routines
- similar situation exist for many other chips that are commonly integrated on the motherboards, and the vendors of those chips are refusing to cooperate

Correct. It's mandated by the U.S. FISC courts (don't ask AMD or intel, they can't talk about it). there are even deeper backdoors that are enshrined in the HW by requirement.

There's no such thing as backdoor free HW these days, even things from ~2012 and older probably had something already built-in.

The closest you can get to "absolutely no BS in my HW" setup is probably a FPGA self-design using something like the RISC-V ISA where you control everything. It's going to be quite limited on performance though.

[alexenv]

You are like little children. as long as we believe in all the crap like freedom on RISC-5, we'll never get it. They are very smart and I understand that if we are strongly squeezed and oppressed, enslaved, then we will try to switch to something new where we will have hope to build the way we want. they made us such blanks as RISC-5, where they thought through all the legal issues, all the legal sides were drawn up so that they, with apparent freedom to us, can always buy and appropriate it. Who's going to stop it? you? Me? that is, if we feel bad on x86, too bad on x86, we will switch to RISC-5, but even there they will be the masters. when you achieve some results there, they will just take it away, they will buy it together with RISC-5 and all your freedom will end. this is how they direct development in the right direction. that's why AMD bought Xilinx. they are putting progress in the right direction. they are now offering us aarch64. they took into account all the loopholes that Linux users used to be relatively free and closed all these loopholes on aarch64. if only it had succeeded, for example, snapdragon would have merged with INTEL and we would have had to start all over again. as for this crap about freedom on linux distributions. freedom may have been only when there were few users. Now, as soon as people come, they immediately begin to tighten the nuts. as soon as a lot of people come, Linux distributions will become as free as windows or there will be even less freedom. their idea is to drive us around in circles, giving us illusions like RISC-5 that we will find the freedom we want there. as soon as we make a mistake and figure it out, they'll slip us something else. we will waste our energy on empty things and will never realize what we want. The plan is simple. as developers, you know perfectly well that without approval and permission you will not be able to do anything in the free Linux kernel. So where is the freedom here?

Cool story bro.

[sophisticles]

I swear, of all the things to get your knickers in a twist about, they found out that they were shipping "non-free code", oh the humanity.

The funny thing is all these clowns that go on about such idiocy have no problem with driving cars, taking mass transit, living in a house, watching TV, listening to the radio, wearing clothes, eating food, going to the movies, literally just living since on one way or another all these things at some point make use of "non-free code" at some point in the production process.

You really have to have a low IQ to be a free software purist.

[alexenv]

because only morons can believe that the linuk core code is perfect, that there are no backdoors in it

Linux core code is open source: torvalds/linux: Linux kernel source tree (github.com)

Point us at the deliberate backdoors you're talking about. Otherwise you're just proving his point over and over again, sorry.

[phoron]

Not meaning to contradict you in any way or anything, just felt like adding something...

You are too vague about the "various factors". Let's de-mystify them, so that we can blame some of the parties involved:
- the blobs which initialize the AMD and Intel CPUs are signed by those companies. They refuse to provide other parties with signing keys. Alternatively, they could have instituted a program which would allow other parties to submit custom initialization routines for signing, but those companies continually refuse to do that

And yet there's PKFail, to show that those who compromise on freedom for security won't get either freedom or security,
or besides Benjamin Franklin, if you solve security by centralisation and added complexity, you will be bitten by incompetence in your supply chain.
In the end you can't have security if you don't understand security, and you can't buy security if all the staff in all your suppliers don't understand security.
So it's better to assume you won't have security. Those digital illiterate that refuse networks and devices may end up being the safest.

- the blobs which initialize the AMD and Intel CPUs are encrypted by those companies, so noone can analyze what those blobs do, so noone is able to replicate their functionality
- both companies refuse to publish essential documentation about the initialization routines
- similar situation exist for many other chips that are commonly integrated on the motherboards, and the vendors of those chips are refusing to cooperate

And the public keeps buying such hardware, and accepting imposition of the use of such hardware for access to commercial, administrative or medical procedures, so the wheel keeps turning.

But somehow the weirdos are always free software zealots insisting on basic principles and resisting broken markets. Well, if you all want to think so...

[turtleidiot]

>get 100% free boot stack
>look inside
>non-free code

[microcode]

can't people teach the kernel to boot on its own without loaders? such an approach would solve many problems.

Coreboot was the natural consequence of trying to do that. Turns out it's not an option for PC platforms anymore.

[davidhendricks]

FWIW to anyone reading this thread, one of the ChromeOS developers replied some background info about the test data (the blobs): https://mail.coreboot.org/hyperkitty...6NYJQPXDLA7CS/

There's also a bug tracker issue here so folks can follow along as they work to fix the problem: https://issuetracker.google.com/issues/374385985?pli=1

[Developer12]

can't people teach the kernel to boot on its own without loaders? such an approach would solve many problems.

What will load the kernel? Where are you going to load the kernel to, when the RAM doesn't work yet? Do you have any idea how complex the procedure is to get DDR4 memory controllers working?