The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive.
Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified.
It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs.
By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.
not knowing about https://ryf.fsf.org/ previously, i managed to find and understand their certification process within a matter of ten minutes. if i was a user of these products i don't think i would feel decieved
Is the poster you’re replying to saying anything about the ease of parsing their policy? He doesn’t seem to be calling it confusing. Rather, he seems to be attacking the supposed (il)logic of its contentions and the resulting consequences.
At the moment this back and forth feels like you’re talking past his actual point(s).
The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software.
Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page:
> AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization)
> AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.
"Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases.
Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.
One of the nice things about the FSF's free software principles is that if you disagree with how they think you should use their software, they're not going to stop you. Nonguix[1] provides solid non-free support if that's what you want. In fact it has a helpful section on microcode updates.
The FSF even condones non-free software (in a rather dorky way) for people whose machines require it[2]. I understand the FSF's principles and am glad they hold to them so strongly, but I would use non-free graphics drivers if I were to install Guix. I do fundamentally agree with the principles of software freedom and I am honest with myself that I am in fact making a moral compromise. Similarly I'd probably compromise over CPU microcode patches, even though I believe I have the moral right to view, understand, and change those microcode updates if I wish to and am displeased that my rights are being violated.
I believe in this day and age where the right to repair your own equipment is under serious threat, the principle that we should be free to modify the machines we own as we see fit is more important than ever.
I fully believe in software freedom (including favoring the GPL), and am trying to push it forward with this argument. I just see using a "6300 with microcode 2019-12-18" as the exact same compromise as using a "6200 with microcode 2011-11-14", regardless that the first blob was loaded at runtime while the second blob was loaded at the factory. Neither one lets me audit or modify my processor. There aren't many performant processors that do let you do such things, so the FSF is willing to compromise on systems with the second type of processor. I argue that they should extend that same pragmatism to the first type of processor as well.
Ultimately, the goal of a GNU/Linux distribution is to create a fully Free GNU/Linux environment. A fully free system would be a worthy goal, but Guix is not attempting such a thing (say by refusing to run if it detects hardware that has non-free firmware in flash). Rather they preemptively compromise by ignoring blobs stored in flash, but refuse the same compromise when those blobs would be loaded at runtime. This is completely backwards given that blobs loaded into auxiliary processors' RAM by Free software running on the main processor are actually more under the control of Free software.
And sure, nonguix exists. But I've gotten the impression that when you interact with the Guix community (eg irc), they will give you a bit of a cold shoulder for using nonguix because it is "not free software", even though you're making the exact same compromise as anyone else with a non-Free microprocessor or non-free auxiliary processor firmware. So ultimately I'm arguing that community norms, as led by the FSF, need to change here. They're stuck with an outdated model that simply ignores embedded firmware, rather than engaging with the nuance of labeling each part of a system as "free" or "non-free"
It sounds like we have very similar beliefs. I think the FSF should acknowledge that microcode updates and such are odious but tolerable moral compromises and that we should continue to work for a future where we have complete freedom to modify, repair, and otherwise use our machines as we see fit.
However, for fun, I'm going to do my best to steelman the FSF position: The use of non-free software when no free alternative exists is tolerable. The material difference between firmware that comes with the hardware or microcode that comes with the CPU versus a downloadable update is that the update is voluntary, and thus involves a willful violation of the principle of freedom. By doing so one becomes actively complicit in the erosion of freedom.
I also agree that they shouldn't be jerks on mailing lists and IRC, but have some empathy for persons that aren't so fortunate that they can eschew all non-free software.
I think the FSF position comes to down to 1. It's what they've always done and 2. They don't want to be distributing any nonfree software, even when it wouldn't become part of the Free environment
Whereas having a background in embedded design, I can't ignore that I have many more devices running nonfree software than Free software, despite trying to use Free software wherever I can. In particular, my fully Free desktop relies on non-free { monitor, monitor remote, keyboard, mouse, USB hubs, USB hub PS (power supply), USB switch, UPS, network power switch, circuit breaker, ethernet switch, ethernet switch PS, GPON terminal, GPON PS, nonfree BIOS on router }, in addition to the contentious non-free { video card, network card, CPU }. Any and all of those things could be replaced with a Free equivalent, but at the cost of attention that would be better spent elsewhere. In a world being eaten by software, the best we can do is hope for well-defined interfaces with nonfree systems, for our Free systems to interoperate with.
Perhaps a good way forward would be to split (Nonguix, Debian non-free, etc) into two separate categories depending on whether a package runs in the main security domain (drivers, system software, utilities/applications), or is to be loaded into an auxiliary processor (firmware blobs). Then after this distinction became widely accepted, the Free-first distros would hopefully become more comfortable including the firmware blobs, making a better user experience for their Free environments without impinging upon the freedom within.
(FWIW your steelman isn't it - it would seem to indicate that buying a computer with MS Windows preloaded is good from a software freedom perspective)
And here is the error of your logic: "is voluntary, and thus involves a willful violation of the principle of freedom".
Principle of freedom, in the context of the FSF, has always referred to user/recipient freedom.
A user voluntarily (of their on unconstrained freedom) making a (informed) choice for themselves, by definition does not violate their own freedom, they are exercising their freedom. You are contradicting yourself.
Complicit-ness can be debated with regards to purchasing decisions, not with regards to updating firmware.
i am not affiliated with FSF in any way. yet it seems to me that there are plenty of people arguing against them in very bad faith. here is the full excerpt in question:
>AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization)
>AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.
>NOTE: 6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates. The 6200 series CPUs have more reliable microcode. Look at this errata datasheet: http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Gu... (see Errata 734 - this is what kills the 6300 series)
>Description: Under a highly specific and detailed set of internal timing conditions during a #VMEXIT for a virtual guest that has multiple virtual CPUs, the processor may store incorrect data to the virtual machine control (VMCB) reserved and guest save areas and may also store outside of the VMCB.
If you are referring to me, I don't see how my excerpt is incomplete or could be seen as bad faith. Libreboot is steering people away from 6300 processors because using them requires explicitly loading a proprietary blob, while encouraging the use of 6200 processors that have an analogous blob baked in at the factory. The real difference is that the former makes you more aware of the compromise.
reading the full excerpt seems to put the reason for rejecting 6300 onto Errata 734 and it was strange to me that this wasnt addressed in your post
however i wasnt referring to you specifically as arguing in bad faith but that seems to be the attitude of some very vocal people here. i included the full excerpt in case the point is relevant. i am not an expert in this field
> reading the full excerpt seems to put the reason for rejecting 6300 onto Errata 734
Well there are two reasons. The first is Errata 734, and the second is that the fix for Errata 734 requires loading different microcode than what was baked into the processor at manufacturing time ("6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates"). I didn't mention Errata 734, because I'm focused on the second reason.
Working back from their reasoning, Errata 734 seemingly does not apply to the 6200 series.
mindslight, i cant reply to you directly so i will do it like this. thank you for clarifying about Erata 734. if Erata 734 applied to 6200 then libreboots logic would make no sense
i take no issue about with critically discussing someones logic. fud and attacks are annoying and dont contribute to a healthy discussion
The FSF don't actually care about such details - sure, they'll deride ME, but they make no attempt to inform users about how it compares with alternatives and which options are better for users. That's because their criteria are not based on technical analysis, like determining what the access surface of the blobs is, but instead on the mere existence of the blobs. To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.
>To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.
For a company that values software freedom above all else this is completely fine. If they are called Secure Software Foundation then your arguments would hold more weight. For example, I really doubt that FSF would claim that GNU Guix is more secure than Open BSD
but security is associated with free and open source software. i think this is a common position of a vast majority of security experts. to make your claim that FSF deceives or misleads people you need to do a LOT more. for example, can you provide an example where someone claims that GNU Guix is secure by design[0]
i think that taking a position that free software supports security and also that free software principles come before security considerations is not contradictory let alone deceptive
[0]EDIT: i just searched the RYF site and did not obtain a signle result for the term 'security'
The factors that actually impact the upper boundary of achivable security are availability of source code (open or not) and reproducible builds. The 4 freedoms do not actually affect any aspect of security, they are orthogonal.
Also, just because the 2 factors above impact the upper boundary of achievable security does not mean an open source software is automatically more secure.
It is conceivable for 2 comparable pieces of software to exist one open source and the other closed source and for the closed source one to be more secure.
There are many reasons why open source software is in practice considered more secure, among others being faster availability of updates and the aforementioned higher upper ceiling of security.
>does not mean an open source software is automatically more secure
well my point is that FSF never anywhere claimed otherwise. if they did THAT would be wrong and irresponsible
>It is conceivable for 2 comparable pieces of software to exist one open source and the other closed source and for the closed source one to be more secure.
sure. well a simple example is that security by obscurity is a valid concept in a right environment
Security is part of protecting your freedom from being compromised. I read this entire thread and wholeheartedly agree with marcan_42. FSF's position to draw a line where none exists is foolish wishful thinking and potentially dangerous.
I prefer knowing that I live in a world where COMPLETE software freedom is close to unachievable and it (COMPLETE software freedom) is a worthy goal to strive for compared to deceiving myself into believing it has been achieved by ignoring anything below a certain level.
Just because I choose to amputate my ability to update firmware does not mean a malicious party might not be able to do so. Anyone with physical access to hardware will still have that ability by using extra hardware. Handwaving the firmware away does not work against an evil maid attack.
>I read this entire thread and wholeheartedly agree with marcan_42
and you are free to do that and i would not say that you are a part of marcan-worshipping-cult or following some dogma
>deceiving myself into believing it has been achieved by ignoring anything below a certain level
if you are stating that this is what FSF believes then you are in fact spreading a falsehood and fud. this is what marcan has been doing regarding FSF the whole time during this engagement
>Just because I choose to amputate my ability to update firmware does not mean a malicious party might not be able to do so. Anyone with physical access to hardware will still have that ability by using extra hardware. Handwaving the firmware away does not work against an evil maid attack.
Unless FSF is claiming that GNU Guix is secure by design, or is free from such attacks, this is just a strawman argument
The FSF is deceiving themselves and others by believing that just because a user no longer has the ability to update firmware on a device, that device is acually no longer running non-free code.
I really do not understand what is so hard to understand that from a free software POV there is no distinction between a chip loading a blob from system storage and a chip loading a blob from it's own tiny updatable flash. Both load a non-free blob. Neither fully respects your freedom. Drawing the line of Respects Your Freedom TM between those 2 is stupid and deceptive.
The users ability to update firmware is also the ability to revert firmware changes (to a old trusted even if closed source version) made by a malicious party. Users do not gain any freedom by giving up that ability. They loose freedom.
Being able to choose between MS Office and Lotus and Star Office and WPS Office (1) gives the user more freedom compared to being stuck with just MS Office (2), even if none of those respect your freedom. Being able to also choose Libre Office (3) is obviously better. But 1 is still obviously better than 2. The existance or absence of 3 does not change that.
With regards to firmware, the FSF believes that 2 is better than 1. That is stupid. How do you not see that?
It is a valid form of protest but Respects Your Freedom TM certified hardware does not truuuuly respect your freedom.
This is harmful because the goal should be hardware with FLOSS firmware with reproducible builds and with the option for the user to add their own signing keys, NOT unupdatable (by the user) closed source proprietary firmware.
>With regards to firmware, the FSF believes that 2 is better than 1. That is stupid. How do you not see that?
your comparison with MS is ridiculous. FSF software is open. do with their software what you like. FSF believes it should not help you with 1 or 2 due to its principles, and that is OK. why wouldnt it be? the source is there so help yourself if you really want something that they are not willing to help you with (even if they often do apparalently)
anyway this whole exchange is becoming tyring to me. a lot of these comments by people seem to be more about vaging a crusade against FSF than it is about discussing issues in good faith. its somewhat dissapointing, esspecially since i only just realised who marcan is. as far as i am concerned, i am completely unconvinced by marcan and co that FSF is a deceptive organisation and that their work is somehow bad for free software. quite the opposite, i am happy that they exist. i say this simply as a spectator. to me the following comment on their website just clearly shows that they are aware that products they certify run nonfree code:
"If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification"
(source given elsewhere in the exchanges)
i do not feel deceived in the slightest. if deception is happening it seems to be regarding FSF's position. take care
You're right, not yet (I wonder why? Maybe they cut too many other corners, or the FSF gave up on the program?), but that entire nonsense was squarely aimed at gaining RYF certification and done with the FSF's blessing.
Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified.
It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs.
By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.