canoeboot
/
cbwww
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

remove stragglers 

Signed-off-by: Leah Rowe <leah@libreboot.org>
master
Leah Rowe 2025-01-10 03:27:11 +00:00
parent 6b04d5ec5d
commit 505832155f
1 changed files with 3 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
site/news/policy.md
View File

@ -67,8 +67,8 @@ So what *is* Canoeboot's policy?
Canoeboot follows a very conservative and *light touch* approach, when it comes Canoeboot follows a very conservative and *light touch* approach, when it comes
to deblobbing coreboot. to deblobbing coreboot.
Canoeboot only excludes *software* binary blobs, plus CPU microcode updates, Canoeboot only excludes *software* binary blobs, plus CPU microcode updates.
completely in line with FSF policy. *In practise, it is mostly microcode *In practise, it is mostly microcode
updates that Canoeboot's build system deletes, along with coreboot Git history updates that Canoeboot's build system deletes, along with coreboot Git history
so that no traces remain of old revisions; older revisions had many blobs in so that no traces remain of old revisions; older revisions had many blobs in
the main repository, but modern coreboot moved almost all of them to third the main repository, but modern coreboot moved almost all of them to third
@ -117,22 +117,6 @@ purpose of this section is to spread *facts*.
Not including CPU microcode updates is an absolute disaster for system Not including CPU microcode updates is an absolute disaster for system
stability and security, and yet, this is one of Canoeboot's key policies. stability and security, and yet, this is one of Canoeboot's key policies.
Making matters worse, that very same text quoted from the FSF RYF criteria in
fact specifically mentions microcode. Quoted again for posterity:
*"However, there is one exception for secondary embedded processors. The
exception applies to software delivered inside auxiliary and low-level
processors and FPGAs, within which software installation is not intended after
the user obtains the product. This can include, for instance, microcode inside
a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
The software in such secondary processors does not count as product software."*
Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
itself. It is simultaneously not giving the OK for microcode *updates* supplied
by either coreboot or the Linux kernel; according to the FSF, these are an
attack on your freedom, but the older, buggier microcode burned into ROM is OK.
This is absolutely inconsistent.
The CPU already has microcode burned into mask ROM. The microcode configures The CPU already has microcode burned into mask ROM. The microcode configures
logic gates in the CPU, to implement an instruction set, via special *decoders* logic gates in the CPU, to implement an instruction set, via special *decoders*
which are fixed-function; it is not possible, for example, to implement a RISCV which are fixed-function; it is not possible, for example, to implement a RISCV
@ -141,23 +125,11 @@ implement x86, or *broken* x86, and the default microcode is almost always
*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
these processors. these processors.
The basis of the FSF's disagreement about microcode *updates* is that they do
believe otherwise; Stallman himself expressed such ignorance to me, in a recent
email conversation I had with him, as of January 2nd, 2022. The FSF believes
that these x86 microcode updates (on Intel/AMD) allow you to completely create
a new CPU that is fundamentally different than x86. This is not true. It is also
not true that *all* instructions in x86 ISA are implemented with microcode. In
some cases, hardcoded circuitry is used! The microcode updates are more like
tiny one liner patches here and there in a git repository, by way of analogy.
To once again get in the head-space of the FSF: these updates cannot do the CPU
equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
more!
These processors provide a way to supply microcode *updates*. These updates These processors provide a way to supply microcode *updates*. These updates
are volatile, and consequently must be applied during every boot cycle. The are volatile, and consequently must be applied during every boot cycle. The
updates fix stability/reliability/security bugs, and their *absence* updates fix stability/reliability/security bugs, and their *absence*
is *technically incorrect*, but Canoeboot excludes them anyway, because that is is *technically incorrect*, but Canoeboot excludes them anyway, because that is
FSF policy. Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16 Canoe policy. Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16
and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make
hardware-based virtualization (via `kvm`) completely stable, where it would hardware-based virtualization (via `kvm`) completely stable, where it would
otherwise lead to a kernel panic. They allow those same thinkpads to be run with otherwise lead to a kernel panic. They allow those same thinkpads to be run with