Does The FSF Really Respect Your Freedom?

There see to be some legitimate concerns with how the FSF approaches microcode and firmware running on a secondary processor which does not respect your freedom and in many ways puts users in danger.

==========Support The Channel==========

==========Resources==========

=========Video Platforms==========

==========Social Media==========

==========Time Stamps==========
0:00 Introduction
0:22 What Is RYF
2:21 Linux Libre Is Dangerous
5:47 Microcode Misconception
7:03 Librem 5
8:11 Broken Down To Core Point
9:27 Why Is The FSF Like This
11:01 Outro

==========Credits==========
🎨 Channel Art:
All my art has was created by Supercozman

#RespectsYourFreedom #FSF #Linux

🎵 Ending music

DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.

[BrodieRobertson]

Just because I don't 100% agree with the FSF that doesn't mean I think you should stop supporting them or they're a terrible organisation. I think overall they are a positive force on Free Software but due to when the organization was formed, there are now areas we can see that either weren't considered or weren't considered a big deal at there inception. You should always be trying to improve rather than just accepting the way it is because that's how it's always been.

[albertopajuelomontes]

The reasoning behind the FSF aproach is that software that is wirtten into ROM and its not user replacable is just equivalent to a hardware circuit.

[nonetrix]

>Be Stallman
>Buy thinkpad
>Libreboot it or whatever
>Remove Intel ME
>x86 is still proprietary and you can't make your own x86 CPU unless you nicely ask Intel

Stallman btfo

[OcteractSG]

What have we programmed ourselves into? It has become abundantly clear, both socially and in programming, that the enterprise-supporting copyright model does not fit with computing. At the same time, there is no better motivator for doing things than enterprise, so it’s no wonder that free software is behind and struggling to fully realize its ideals.

[Gerdoch]

A 100% 'FOSS' x86(-64) laptop with zero microcode is pretty impractical as it stands right now. You have to use ancient, VERY specific hardware.

[dimasskarabas]

For those complaining about FSF containing closed firmware, try writing and devugging your own BIOS for a modern motherboard.

[Jenny_Digital]

Hi Brodie, I would like to help make clear the distinction between an FPGAs code and that of software/firmware. The code in a Field Prigrammable Gate Array describes the precise gates and interconnections between them which is to say, the sea of gates are configured as to what the circuit should _be_, whereas the software as I’m sure you’ll know, tells a processor what to _do_. It’s still important from a trust and audit point of view however despite not actually being software.

[josephbrandenburg]

Still gonna support the FSF, the beauty of Free Software is that I can build my own kernel with whatever combination of firmware and blobs I want. Some people choose Linux-Libre and I think that's their right.

[liorean]

I would say there are four levels here - Actual circuitry, actual non-rewritable ROM, offline-programmable circuitry including some forms/usages of EEPROM or FLASH, and anything online-programmable including some forms/usages of EEPROM or FLASH. Basically, if you can change it at runtime, it's part of the operation of the system and should be considered product software. If it's actual circuitry or actual ROM, then it's part of the machine. So the question really becomes what to consider the offline-programmable circuitry. Since I have lot of them, let's consider the Raspberry Pi machines:

The RPi<4 hardware is not circuitry-complete - the CPU cannot load its own initialisation code into memory from anywhere. But there is a separate processor that has the circuitry to load the initialisation code - the GPU (Video Core IV). Besides circuitry, this part contains a ROM (I was not at a simple search able to find out if it is ROM or PROM) that holds the stage 1 bootloader. Basically a very minimal proprietary program whose actions is to look for a specific file path (bootcode.bin) on a boot medium containing a FAT16/32 partition. Where it searches for boot media depends on an OTP ROM. Once this specific file has been loaded by the GPU, it is run (still on the GPU) as the stage 2 bootloader. This stage 2 bootloader is a proprietary binary blob from Broadcom. Anyway, it has as its main purpose to load the stage 3 boot loader (the GPU firmware in start.elf) into memory for the GPU to run and enable and setup the CPU. Once the CPU is started, it loads the stage 4 of the boot process (no longer strictly bootloader), in linux systems initramfs and kernel. Which finally loads up the rootfs and boots up the user system.
Here we have one binary blob in ROM, so we can consider it part of the machine; one binary blob on removable media, so we can consider it non-free product software; one compiled bootloader that is free software (except if the user chooses a non-free OS); and one OS initialisation system that is free software (same caveat applies).

To make the RPi<4 designs 100% free software, we'd need to replace the proprietary stage 2 bootloader bootcode.bin. The stage 1 bootloader can be considered part of the machine, however.

[Vicorcivius]

I really think this whole Free Software thing is a little cult like, What matters just as much if not more is Open Source Software and Transparency. As in being able to know what is actually running on your device and being able to have access to the code on your own device and being able to modify it for personal use.

I do not care if the code is free or not free, If it does what it's devs say it does, If it works properly and is not obfuscating what it is doing while telling the user it is doing something else while doing something malicious in the background. If you can view the source code. I have no problem with that.

I see no problem running some proprietary code as long as that code is open source and meets the above listed criteria.

[ElectricEvan]

It was an exception that made sense in the beginning because the open source movement didn't have the clout or momentum to push for open firmware (including microcode). I suspect that now they could do better. Particularly now that we have open source toolchains for FPGA development on some silicon (smiles at Lattice for not breaking this). But we have also seen open source projects silently walk away from their plans to do open firmware (nouveau) because the hw vendor (nvidia) came an offered resources if they did so. I feel like gpl3 (not a fan of) kind of required an almost viral open sourcing of everything used with it as another way of fixing this one the movement got momentum. The problem was ... well ... it was gpl 3... So how do we fix it now? Open source software running on fpga's or asics designed with open source toolchains (trellis/icestorm/etc) to replace the CPU, GPU, and with open hardware the wifi. It's a lot of added engineering but someone should do it just to raise the bar.

[thomasschlieter]

Is there a RISC V System which is complete open?

[cirno]

The problem is hardware manufacturers. CPU manufacturers in particular. AMD PSP and Intel ME are to blame for this shit.

What we seriously need is a competitor that has open source secure enclaves. The issue is that DRM would be impossible for 100% enforce if the user could control their system like in the old days.

[lvmlvm]

I would like to point out that the linked Ariadne article states "partially mitigated through a microcode update."

"Mitigated" already means - less likely but still possible, and I can only interpret "partially" as "even less effective than normal mitigation".

So I don't think it is fair of them to say that a CPU without this microcode is "broken" in another paragraph of the same article.

There is no way to really fix specter and meltdown without physically building a new CPU, because these vulnerabilities are at an architectural level.
They can be made harder to exploit through software both at kernel level and microcode level, though at least kernel patches have significant performance price.

So, the real choice users face here is: use the processor with a known issue, or load a proprietary microcode blob that might help slightly, but might also introduce new problems at the same time.
I would say that decision is not as cut and dry as the linked article makes it seem.

By the way, if reverse engineering CPU microcode was achievable with reasonable effort, we would have free replacement for those blobs right now, and this whole thing would be a non-issue.
There has been tons of reverse engineering done to support devices on Linux which the manufacturer never supplied drivers or even specs for.

So while I am not an expert, I think it is safe to say the reason we do not have any free microcode alternatives out there, is because creating one is very seriously hindered either technically, legally, or most likely both.

[SXZ-dev]

Wait was there a software patch for Meltdown? I thought CPU vulnerabilities could never be patched with any kind of software, even microcode.

[knixie]

Protest at amd and Intel instead of making users vulnerable

[Omnifarious]

Binary blobs make me very nervous. I can understand why the FSF doesn't really have a very good policy for dealing with them. Maybe this can be solved for CPUs with RISC-V.

[Achrononmaster]

Respecting freedom is different to guaranteeing or giving freedom. It's not the fault of the FSF that to get useable GNU+Linux computers one needs the proprietary firmware and drivers. I'm not a shill for the FSF (I'm a physics and macroeconomics nerd) but i do know political economy, and realpolitik, and anyone can see that device + software compatibility is a two-way street, so involves realpolitik and profit driven power plays. Your video is wonderful for highlighting these issues, and is (I think should be viewed) a big positive for getting people to help the FSF on their side, which is the freedom respecting side that desires to move to freedom guarantee with usability for normies. Thanks.

[Xankillr]

I think they should just make two certifications - RYF100 and RYF50. RYF50 is basically the current requirement and RYF100 requires 100% free software including all the microcodes and stuff. That gives much greater transparency and also provides something for companies, governments, etc to work towards achieving.

[Kispalkovich]

I think there should be two certifications, e.g. an A and B tier ry.f