I find the approach interesting. The goal of the Free Software folk was never primarily to "provide the best information to the end user," it is to "preserve software freedom." Guix looks like a possible technical path to do that. Will it work? Will it cause harm? I don't know yet.

Either way, the law-slash-tech has always come before "ensuring that it's public-understood and ready" as it should.

"Freedom" through lack of information is the kind of tactic that repressive regimes use to control their populace. It has no place in an organization claiming to further and support true freedom.

I'm not speaking for them, but I'm pretty sure they would say something in the realm of "the information provided by your updates is a false sense of security, so why WOULD we pass that on?"

And literally everyone signs their firmware.

Firmware that ships with the actual CPU is a bit 'safer' because it has a lot more users and eyes looking at it (sort of). Depends on what your attack vector is.

Another aspect is that while this policy is worse for Linux-libre users, it is sort of a protest against needing these binary blobs. The hope is certainly that adoption of Linux-libre would result in AMD/Intel not having these non-free software requirements.

Microcode is a bad example because the updates are encrypted too, but for the vast majority of the blobs that the FSF hates so much, at least you can look at them and audit them with a disassembler. Meanwhile, the devices with giant firmware ROMs that they openly endorse are not auditable, as you can't see the blob. This policy is making it easier for manufacturers to ship backdoors that will never be detected.

to the said point, this is definitely a VALID security concern. FSF needs to make these concerns clear. you seem to be very invested in this matter. have you raised these concerns with them?

EDIT: having thought about it some more. doesnt isolating blobs to ROMs restrict the problems to ROMs? i mean non-RYF certified hardware already has this problem. the strategy might them be to focus efforts on opening up ROMs. note that this is simply a question. i am not an expert in this field but i am trying to form an informed opinion

It gets ignored.

I believe it is for the same reason religions ignore issues.

The FSF totally acts as a religion. The church of his Gnusance St. Ignutiutus. And just like religions it pretends to hold an ethical position while making compromises for practical reasons.

Compare religions claiming:

- Killing is bad, unless it's about opponents in war. - Slavery is bad, unless it's outsiders who are slaves. - Blobs are bad, unless they are stored on chip flash.

The FSF gets criticized precisely for this hypocrisy. And just like religions ignore criticism about their inconsistencies so does the FSF.

so is FSF dogmatic or is it practical? surely they cant be both

A really simple example is GPL violations. Pure dogma would require that they try to fight a whole lot of them, since they occur all the time and they're clearly in the legal right.

But they don't, and that's the MUCH SMARTER way to go.

Why this Guix thing strikes me as smart is that it's about "reinforcing modularity." They can't free up EVERYTHING, but they can make the software work different so that it's harder to pretend that everything is all the same.

to clarify my previous post, i was using the term dogmatic in the context of some people claiming that FSF is a cult

What it can't conceive of is an organization with big picture goals that aren't "making a profit" that require strategy and even "real life experimentation." That's what's happening here; y'all are just confused because the FSF feels like "religion" because it's not going for profits, but somewhat acting like a for-profit, in that it's picking and choosing battles.

To respect these principles the Guix project (and others) asks to not discuss non-free software, hardware support, or related matters on official channels. These questions and non-free packages are best left to any number of other venues. Guix does not actively hamper a user’s ability to load non-free software or firmware (see freedom 0), but will not support this in any official capacity. That said, the community is very nice and will not kick you from IRC if it comes up (more likely you’ll get some private messages directing you or helping you out), but better to remember their rules.

I think that says all.

"Hush, hush, and don't look under the rugs!"

This is diplomacy. This is exactly the correct way to act when you are diametrically opposed to something that is widely used, popular, and prevalent -- when you hate something; but understand that other people don't and you're going to have win them over.

The Guix project states clearly that it does not support these uses of the software, but that users are free to use it - because the software is released under the GPL.

So what exactly is the problem? The Guix maintainers consider their users to be competent and able to make decisions for themselves - the charge of ‘evil anti-user behaviour’ isn’t so inappropriate as it is laughable and immature.

Also, as other commenters have mentioned, I have never had a warning that I need to install new microcode from any distribution. As a matter of fact, it would not surprise me if other distributions were not to give me a choice in installing new microcode - if I’m running underpowered hardware (not uncommon for hobby Linux users, especially if the hardware is known to be well supported), and I don’t have much to lose on that hardware, having mitigations against things like Spectre/Meltdown is a calculated decision given the performance impact, so why shouldn’t I at least be able to choose? With Guix, this is a one-liner in your configuration.scm file.

I'm sure Guix allows users to choose (it has to, thanks to Freedom 0, as you say), but by choosing a kernel by default that chooses to withhold information from its users, it is encouraging decreasing user knowledge. That is something that people should be aware of, and honestly, something that should be considered a bug to fix. We can't allow the proliferation of schools of thought that promote not educating users about their options, justified by ideology.

For what it's worth, disabling microcode updates in other distros is just uninstalling a package (or not installing it in the first place; my distro of choice, Gentoo, does not install it by default).

There is an ideological battle here, and despite the way you frame it, it is between people who believe that users should be empowered to know what the software they run does, and people who don’t. Linux-libre sits in the camp of the former. I don’t know into which camp you fall, but your argument suggests the latter. I personally use the upstream Linux because it works easier for me and the hardware I have, but I have no bones about the fact that I am running non-free software, that that ideally I would have hardware which supported fully free software.

Also, as I said, the Guix maintainers believe that their users are competent. Guix users know what they’re getting into when they run Guix, at least when they get to the point when they would drive it daily or run it on a system they see as critical. We know that microcode isn’t included when we use Linux-libre, because it is non-free - and that’s just the way it is. Saying that the Guix project is withholding information from us is incredibly patronising. It’s not a big conspiracy - the project, along with the rest of GNU, is openly in favour of maintaining repositories of fully and solely free software, to the exclusion of all non-free software. And it goes without saying, it is not the job of people in the GNU Project to educate people about the perks of running non-free software - there already exists a wealth of resources about how people can go about doing this, and it does not align with the clearly stated goals of the GNU Project.

This is about withholding information about an update to the proprietary microcode they are already running. There is absolutely no reason not to offer users this choice, given they're stuck running the ROM blob to begin with. The only reason the FSF and Linux-libre do this is because they want users to feel better by not knowing about the blob they're already running. There is no freedom gained, only the illusion of freedom. Users don't know what their ROM microcode does just as much as they don't know what the update does. The only thing we know is it fixes a bug.

I believe a world where all software, firmware, and hardware is free would be ideal. I also know that is not the world we live in, and so I believe in empowering users with the information about what options they have, what the security/freedom/privacy/etc tradeoffs are, and letting them make their own choices. The FSF's push for restricting information so people believe they are not running any nonfree code is diametrically opposed to my views for this reason. I believe having the illusion of freedom is harmful to the cause for software freedom, as it obfuscates the reality of the current state of affairs. Every single die-hard FSF fanboy needs to learn about the 27 blobs running in little ROMs inside their computer, so they stop believing they live in a fake freedom utopia and come to terms with the reality we live in. Maybe then we'll have even more people pushing for firmware freedom.

I'm not even saying Guix should ship the update. But actively censoring information about the existence of the update? That's just ridiculous. Your users are already running the blob. Stop trying to pretend they aren't and tell them it's broken already. How is it better when users are stuck running broken proprietary software when a fix is available because you refuse to inform them about it? That's completely irrational.

Incidentally, this is a falsehood:

> closed-source, unauditable binary blobs, which constitute a fundamentally greater security risk than any auditable code repository ever could

This kind of absolutist view is another problem with this school of thought. Blobs can be in a position where, by the nature of their access or lack thereof to the rest of the system, they pose minimal security risk even if presumed completely evil. This is evidently a much lower risk than, say, low quality open source code in a position of extreme privilege with a large attack surface. Auditability doesn't mean things get audited or all bugs fixed. I have no problem trusting that a blob in a harmless I/O microcontroller poses little to no security risk to me over, say, certain open source cryptography/key storage implementations I've seen which raise a million red flags. Context matters, and the FSF's refusal to consider any context or nuance is also hurting users by not empowering them to make the decisions that are the best for them.

who believes this? why are you constantly being insulting? a lot of linux fanboys think that if you run linux you can't get hacked. does that make linux dishonnest? of course not! there are misinformed people everywhere. having been in this exchange for about two daya i learned that FSF does a very good job to inform users about what using their products entails

No mention of the half megabyte of proprietary Bluetooth stack firmware (with significant security and privacy implications) that's in that dongle which supposedly "Respects Your Freedom".

https://ryf.fsf.org/products/VikingsX200

No mention of:

* Proprietary CPU microcode ROM (full access to CPU/memory, security critical)

* Proprietary embedded controller firmware (H8S, connected LPC bus, full access to all memory, security critical, might be able to cause physical destruction / a fire with the right GPIO abuse)

* Proprietary TPM firmware (connected to LPC bus, full access to all memory, security critical)

* Proprietary USB camera firmware (connected to USB port, very large attack surface for OSes)

* Proprietary Bluetooth module firmware (connected to USB port, etc.)

* Proprietary USB card reader module firmware (connected to USB port, etc.)

* Proprietary SATA HDD firmware (can access/modify all user data, security critical if you don't use FDE + integrity)

And those are just the ones I could quickly pick out from the schematic; pretty sure there's at least a couple more major ones and even more minor ones. All the other laptops they endorse are in a similar situation.

How, exactly, are the FSF informing users about the devices they endorse?

BEGIN

> 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.

>We want users to be able to upgrade and control the software at as many levels as possible. 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.

END

this explains their decisions in terms of their software freedom ideals, and its perfectly clear. i keep trying to explain to you that FSF is not about doing their best in terms of security. FSF is about doing what they believe is best for software freedom. althought it would be nice, i just dont see why they MUST inform their users about security entailments

of course, it is perfectly fine to point out security flaws in such an approach, but FSF is not selling security, and since the original topic is GNU Guix distro, GNU Guix does not market itself as a security-centric distro. why is this so hard for you to accept

alot of your argument rests on failure of their logic and bluring of a clear distinction between hardware and software. fine, it is a VALID point, but it is a corner case. FSF has taken an approach they believe deals best with such corner cases and explained their reasoning. they might be right in their approach, they might be wrong. you cannot satisfy everyone and not accepting that is just simply infantile

FSF is a pretty large organisation. for large organisations some form of bureocracy becomes necesary to achieve normal functioning. however, bureocracy will always entail some ilogical elements, esspecially in corner cases. that is just life, i believe

It is quite self-evident that not being open about the existence of proprietary code is not the best for software freedom.

I know about their certification process; my entire argument is that their criteria are terrible and the lack of transparency about specific devices and what firmware they contain deceptive. You bringing up their criteria repeatedly isn't helping you counter that point. This silly loop of "The criteria suck. / These are the criteria." doesn't get us anywhere.

If the FSF believe in software freedom, why are they not informing their users about the nonfree software that exists in the devices they sell as "Respects your Freedom"? I'm not saying "why are they certified here"; fine, they have their rules. Why are they not documenting how these devices interact with those rules? Why are they obscuring all of this? What do they have to gain by keeping people in the dark?

To me it is just very clear that they're doing this because they are trying to build a narrative that is different from reality, and the only way that narrative works is if people don't discover the problems with it. Your opinion may differ, but everything I've seen about the FSF's behavior in recent years points towards that. If they wanted to be honest there would be no reason not to document those firmware blobs.

i think that how you framed your concern in this last point is valid from a security point of view. as someone who values knowing security implications i support the argument that they should improve their work on security matters. in saying that, to me FSF is certainly no worse (i would think alot better) than closed source vendors, including ms, apple, intel, nvidia etc as far as making their users aware of security problems is concerned. i actually think that every device should come with a cigarete packet style label that says "might include backdoor inside", not just FSF products. in fact, maybe if only FSF did this, it might create an impression that only their products have this issue

So yes, the FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations, while Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device. And you can put Linux on those Macs and run a fully open source kernel and userspace - not very different from those laptops in the end. Think about that.

Of course, I am very happy to talk at length about the design of these machines with everyone, and I want all the users of my software to be aware of these things (yes, there are a ton of blobs here - the amount of damage they can do is less than the blobs in the RYF laptops, but they still exist), as well as the things we don't know (e.g. some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable, but we'd like to find out and if it is, that would be a firmware bug to report to Apple). I believe that in order to make an informed decision, users need to have all the information.

but they are promoting such devices on ethical concerns, not on security concerns. they are not deceiving anyone

>Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device

you mentioned FSF fanboys before. there are way more Apple fanboys who are convinced that their Apple products respect their privacy and that their devices are impenetrable. what is worse, Apple markets itself based on this grotesque misperception!

if security and privacy is a vital concern for people, Apple devices are NOT products that should handle their security concerns! you promoting Apple as secure makes you guilty of the very thing you accuse FSF of actually

i would absolutely love it if there is a public non-profit organisation like FSF that is security/privacy focused - eg Secure Software Foundation - that would employ security experts to analyse and audit security and privacy of all software, free and non-free, and of course always open their findings immediately. moreover, i would definitely hope that such an organisation would be as autistic and unwavering toward open security and privacy as FSF is toward software freedom :)

the fact of the matter is, while you can support both free and secure software seperately, they are seperate matters. it is possible to come to a conflict of interest type scenario. secure-software and free-software, although often sharing the same concerns, are simply not the same thing

You're mixing up software and hardware. I have no strong opinion on the security of Apple's (macOS) software from a user perspective. It's a proprietary OS. It gets some things right and some things wrong. There have been privacy concerns (e.g. the CSAM mess). I use it for browsing the web sometimes, but I wouldn't make it my main OS.

But Apple deeply cares about platform security, and notoriously, iOS devices are some of the most secure consumer devices available. This isn't marketing bullshit - their designs are actually that good, which is something I can say as a security professional. You may or may not agree with their motivation, which ostensibly includes both customer security and keeping an iron grip on their iOS devices. But the end result is they have built excellent silicon designs with advanced security features and a very security-conscious architecture throughout. The same stuff that makes it hard to jailbreak iPhones. And so now that they stuck them in Macs and unlocked the bootloader, would I buy one? Of course. And put Linux on it. And so should you*, if you care about security. There really isn't anything else done nearly as well as these things, at least not at a performance level we'd consider decent in 2021.

Yes, it might surprise you coming from Apple, but it makes sense because they did this for their own benefit. It just so happens that their motives end up with a result that aligns with what I want. And so I'll take it, thanks.

I still won't use an iPhone, though.

* Okay, maybe wait until we're done porting things and it runs well.

i think FSF fights against non-free software because it considers it an evil for a society. i have no problems them fighting this fight, and i dont see any other candidates able to fight that fight on their level. i think that people who care about free software should at least respect them

on the other hand, i think security and privacy is a seperate fight, extremely important. if you form an organisation that defends security and privacy as much as FSF defends free software, i will definitely support it and you

No, no no. This is wrong. You don't need a nested hypervisor to make an undetectable backdoor. If you you audit all network traffic from a separate device, most backdoors are detectable, because a backdoor wants to have some effect that goes outside your system and that is the obvious route. But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.

So the M1 firmware is meant to be updated, right? Proprietary updates are the means by which a company exercises unacceptable control. The next update to the network card firmware could check the signature of the OS and stop working.

> some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable

Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open? Seems more likely that this whole theory of yours has a whole in it, that some firmware does have access to change important data.

Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties. Well, you may argue that that is more important than software freedom. Ok, but, then that vendor can then make whatever terms and conditions it wants on those updates, and that includes breaking your security. So, one day, the vendor says: run our proprietary updating software, is every user going to reject it because they realize the security implications? No. And the vendor says: our firmware updates are only distributable through MacOS, so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux. Sounds like a good way to kill GNU/Linux for 99% of users who don't got time for that. Wait, isn't that the situation for M1 laptop users? Riiight.

Look, I'm not a fan of pulling on credentials, but I've literally spent the past year reverse engineering these devices. If you're going to tell me I'm wrong about my security analysis, I hope you've done your own.

> But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.

Not when you can literally flash these devices from scratch (DFU mode) using a public OS image from Apple. That guarantees any preinstalled backdoors go away, since it's a complete wipe (you can do this from a Linux machine, by the way - I just added support for the latest M1 devices and OS to idevicerestore a few days ago). All the runtime components that remain booted while the OS runs are not encrypted, and thus Apple can't hide a secret backdoor in them.

> The next update to the network card firmware could check the signature of the OS and stop working.

The network card is behind an IOMMU and sees exactly what the OS wants it to see. It has no way to check the signature of the OS.

This whole argument is moot anyway, because of course Apple could release a new OS/firmware version that removes the bootloader unlock tools. I've had this discussion a million times already. Apple spent a significant amount of time developing these tools and the infrastructure to allow these unlocks, and I do not believe they would ever do this, as it would be a massive 180 and incur a huge PR hit, nevermind expose them to legal action. If you believe otherwise, then don't buy these machines, or just never update the firmware once you get one. Also don't buy any Android phones, any x86 PCs with Boot Guard, etc., as they all suffer from the same hypothetical retroactive lockdown threat.

> Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open?

We are still reverse engineering these machines. It's not just the IOMMUs. There are other layers of address filtering. We don't know what those streams do, therefore we can't say whether they're evil or not. Given how carefully Apple has designed these things to prevent this, I have no doubt that if there's a path for one of these coprocessors to access all RAM, that's a bug, and if I can confirm that, that'll be an email to [email protected] with a 90 day disclosure deadline, and they'll fix it. It wouldn't be my first rodeo with Apple product security either. They're good, but they're human. They make mistakes.

But we can't say that right now because we literally don't know what's plugged into that port on the IOMMU. It could be a hardware block with an address filter or otherwise controlled by the main CPU anyway. Or it could be outright unused and a vestige of something they were doing on iOS. I can certainly tell you that the main IOMMU port used by the coprocessor subsystem in question does not have access to all RAM. They've been very careful to design the whole SoC like that. If there's a hole, it's a bug.

> Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties.

You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom. In fact, most devices with the kind of little ROMs the FSF loves to ignore, like keyboards, would not use signed firmware if they had a RAM design instead. That means you absolutely gain freedom with the RAM version - the freedom to reverse engineer the proprietary firmware and write your own, or install an open version someone else has already made.

> Wait, isn't that the situation for M1 laptop users? Riiight.

I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet. You can, however, already use DFU mode with another Linux machine running idevicerestore to apply these updates without wiping the whole system nor requiring a macOS install, if you really want to (though it's not the best method because it wipes some stuff that makes it not completely seamless, but it doesn't wipe your OS).

> so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux.

Or you could just dual boot, which is how I expect 95% of our users to use the system. We recommend keeping a macOS install around at this point for various practical reasons. The machines natively support multi-boot and we take full advantage of that. Please learn more about the system architecture before making up FUD.

You're saying that a backdoor can't be secret if it is in an unencrypted binary. That sounds wrong to me. Are you going to decompile and audit the entire OS to find a backdoor, I don't think so.

> I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet.

Well, that is nice.

> You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom.

You "could". In practice, software vendors relies on the updates to abuse their users. For example intel microcode updates have a license that says: you agree not to reverse engineer it. Security updates for printers come with functionality to stop working with third party ink. Oh, you are a sophisticated user and handle it all. Fine. And of course, FSF certainly encourages reverse engineering: if you want to buy something for the purpose of reverse engineering, FSF does endorse that. For everyone else, think it's a perfectly fine position to simply say, we don't endorse opening yourself up to an abusive relationship.

No, you’re ignoring the crux of the issue, which is user freedom. Why are you so insistent that Guix wave the flag for Intel and allow its users’ freedoms to be even more flagrantly violated by shipping updated microcode? Why does the FSF not openly publishing certain kinds of information amount to censorship? - do you think that, if they were to remove certain blobs from the kernel but leave in these nebulous notifications that microcode updates are available, it wouldn’t be censorship?

Talk about a bad user experience by the way - what you suggest is for the maintainers of Linux-libre to say ‘oh, by the way, there are critical updates to microcode running on your processor, but we’re not going to give them to you.’ That’s antisocial nonsense. Should they tell users about updates to all the other drivers in the kernel which they don’t ship either? Give me a break.

I am currently, at this very moment, running updated Intel microcode on my Guix machine. Every Guix user who has used the distro for more then 5 minutes knows that a) you can track any channel you like containing packaged software, and b) there is a popular channel which contains some useful non-free software. They know this because it takes about 5 minutes to use a search engine for, say, ‘How do I get Nvidia drivers on my Guix System’, which will lead you to nonguix. What exactly is your problem? Do you think Guix users need to be babied?

> Auditability doesn't mean things get audited or all bugs fixed.

Correct! But it means that they can.

Why won’t you respond to the fact that Guix users simply don’t feel hurt by this? You have taken it upon yourself to speak on behalf of a community which is perfectly happy with the existing arrangement - that the default kernel is built on Linux-libre, and they are free to use any other compatible kernel they like, including the upstream.

If you don’t like Linux-libre, don’t use it. If you don’t like Guix, don’t use it. Your pearl-clutching about these projects’ violation of their users’ rights is unwarranted, unwanted, obtuse, and very annoying. If I didn’t know better, I’d think you had it out for FSF.

I’ll leave that as my final word on this because this conversation is fruitless and pointless. You are moralising on the behalf of a community that you are not a member of and that doesn’t care for much of what you have to say for them.

>If I didn’t know better, I’d think you had it out for FSF

given the ammount of bad faith in the threads i think it definitely looks like a campaign

You can regard it as two separate features: one that's needed for the CPU to function, and another that's the door for more code being added. In that perspective it's better to go with preventing additions.

If there are issues with what are initially released and you do not patch you do not get those fixes.

So they could add stuff but they definitely will fix stuff. Not updating could be more dangerous then updating.

Sure it would be nice to have it all Free Software, but then we shouldn't treat hardware as a magic black box we don't care about.

Furthermore, I haven't seen any device that actually ships significant (ie non-bootloader) firmware in "ROM". It's usually in flash, meaning its contents are mutable but less legible to the Free system than if they were loaded every time by a Free driver.

Assuming you're able to track it at all. If the hardware does not provide any way to read the blobs, then how do you track anything? Decap your CPU and stick it under an electron microscope? Much easier to inspect a file on my filesystem.

Free software isn't about each of us individually fixing the problems. Nearly exactly the opposite.

I agree, if that's the position of Guix, I don't want it in my machine.

It had to be fixed, but your thesis that anyone was actually owned by these security issues because they didn't want to apply the mitigation rounds to at most 0.0% with an infinite amount of zeros before a 1.

The "nonguix" channel mentioned in the article does have Intel and AMD microcode for users who want it. This is similar to Debian, where you have to opt-in by enabling the "nonfree" repository and "apt install" the microcode package corresponding to your CPU.

> where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode

Is not ok

https://news.ycombinator.com/item?id=29290087

...at least, I don't see any such code in the actual deblobbing script: https://linux-libre.fsfla.org/pub/linux-libre/releases/5.15....

edit: since you called linux-libre a "fork", I feel compelled to point out that Linux-Libre is just the vanilla Linux kernel with that script applied. No more, no less.

    # Do no recommend non-Free microcode update.
    announce X86_LOCAL_APIC - Undocumented
    clean_blob arch/x86/kernel/apic/apic.c
    clean_kconfig arch/x86/Kconfig X86_LOCAL_APIC
    clean_mk CONFIG_X86_LOCAL_APIC arch/x86/kernel/apic/Makefile

LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.

Can you buy anything at all on the internet?

If attackers who cannot add a comment to their exploit are in your threat model.

Personally, I've been using a browser extension that blocks JS unless it has a comment reading

> This code is NOT evil or malicious!

at the top. Haven't been hacked yet!

https://9to5mac.com/2021/03/11/browser-based-attack-affects-...

Turns out you don't need Turing completeness to perform microarchitectural side channel attacks. This is yet another way in which the "all my software is free, therefore I am safe from attacks" fallacy breaks down.

Nevermind that, as pointed out by other replies, LibreJS provides zero security. It relies on scripts voluntarily declaring that they're freely licensed, and if they do, they're allowed to run. The extension doesn't care whether the script is malicious or not.

I am still safe.

If you update your CPU microcode to something that can't be checked, you're already sacrificing security.

EDIT:

But yes, I understand people complaining that FSF rejects proprietary software but is OK with some forms of ROM which in turn may be very similar to "proprietary software you can't change".

Well, I never asked their reasons to someone from inside the FSF, so I my knowledge about it can improve. Nevertheless, I can see some points:

  - AFAIK, the form of accepted code is only for "secondary processors" and can't take over the system or compromise it,
  - having things in ROM forces manufacturers to maximally simplify it,
  - having things in ROM forces manufacturers to implement more features in software that can be checked and
  - having things in ROM forces manufacturers to be extra careful when implementing it.

But indeed, it would be very good if someone from FSF could better explain it.

Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

I don't check all the software I use myself. But I use open-source software with the peace of mind of someone who knows that the incentives to abuse me are simply not there and the fact that right now that are hundreds of people/bots checking it.

> Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

State actors are not the only threat. Think about arbitrarily disabled features, DRM, programmed obsolescence or simply not allowing anybody to improve/fix it after the device is abandoned by the manufacturer.

As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?

There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to more easily find where or why the bug happens. And yes, people do it.

> hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?

Yes, this is more serious. But would need a compromise on packagers side and an uninformed (or automated) update on my side. Considering an update with such a vulnerability would affect initially a small fraction of users before being discovered, it is very unlikely that this hypothetical would have a big impact.

Also, your automatic checker examples are related to the project’s size and importance, not to FOSS alone. It is very welcome but your average one-person C project that is installed on everyone’s system doesn’t benefit from such tools.

This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_.... Any links to your argument?

The fact remains, every type of software is ripe for bugs and security measures must be taken so those bugs won’t become exploitable.

https://www.crowdsupply.com/sutajio-kosagi/precursor

Of course, then you get a RISC-V running at 100MHz. If you want something faster, you need to trust your CPU provider. There's no way around that; silicon is not end-user introspectable.

Yeah ok now we are in the religion side of things, since you cannot check the silicon...well i stop here, not worth my time.

BTW: The power microcode is opensource.

READ.

The microcode is opensource..

Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around that that does not involve using FPGAs and restricting yourself to 100MHz CPUs.

By the way, I googled POWER9 microcode and was not able to find any source or reference to it. The source code for the firmware running on various auxiliary cores is open source. However, the CPU cores do contain microcode for executing more complex instructions, and I am not finding any reference to this being open source.

>>>since you cannot check the silicon...

And since you have problems using google too:

https://www.sbir.gov/node/1620879

>>A small business has already shown that a completely open source solution (to include CPU firmware, CPU Microcode, Baseboard Management Controller (BMC), BIOS boot code, power management, etc.) based on a high performance CPU is possible.

Imagine who that "small business" is?

FYI, IBM loves to use the term "microcode" to include side CPU firmware and such. This is different from Intel "microcode" which strictly refers to the instruction dispatch part. Is the instruction dispatch microcode in POWER9 open source or not?

None of these are it: https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware

>>CPU Internal Firmware

>>CPU External Firmware

Maybe it's time for you to have the realization that POWER9 has proprietary microcode just like Intel. At least it seems they probably have less of it, and they do vaguely document it in the CPU manual (they have micro-op classes and counts) but it's there, and I don't see any real source code anywhere. They also have patch registers, so you can't even say it's not updatable. The POWER9 manual mentions six Instruction Mask Registers per core, but these registers are documented nowhere (I just spent a good 30 minutes digging through the giant register documentation PDFs and HCODE source, but I couldn't find anything).

Is this better than Intel? Yes. Is it "fully free"? No. Nothing's fully free. Which is why we need nuanced analysis, not the nonsense arbitrary lines the FSF draws in the sand.

if i dont have options for alternatives, i think its completely rational to use something without trusting it. i would say that this should be a default attitude

However the distinction between blob on chip flash and blob on system storage is nonsensical to me. I would much rather have a sandboxed untrusted part I can update rather than a sandboxed untrusted part that I can not update.

Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period. Doesn't matter where they live. None of us are arguing in favour of blobs.

this makes it sound like FSF supports these blobs. how i understood the situation is that they tolerate them until an alternative presents itself. this is a valid position to take and does not make them hypocrites/cult/religion etc

actually since you work with macs, do you think Apple respects your freedom or do you think they are more ethical than FSF?

But they also never claimed to be ethical. They never claimed to guard a moral ideal. They have claimed many things (protect privacy of users, guarantee security of users) which they did not act upon, and they have received flack for that. But they didn't claim to be ethical. Not even in a aspirational way like Googles "Don't be evil" moto.

The FSF, however, claims that ethics is it's prime driver. And by endorsing hardware with proprietary blobs (placed on chip flash instead of system storage) they display hypocrisy. They choose the very pragmatism they criticise others for choosing.

And that is something religions do aswell.

I have asked you why is the line there and you have not answered.

Whether Apple is ethical or not is a different question. There is plenty of criticism to be fired at them for various issues. That's a personal call for people to make. I'm not saying you should go buy Apple hardware. I'm saying it's significantly more trustworthy from a security and privacy standpoint than x86 machines. Do they respect my software freedom? About as much as the RYF machines. They both let me run my own OS and they both rely on proprietary firmware for various things. The FSF's certification criteria do nothing for my software freedom (which has nothing to do with whether blobs are in ROM or RAM), they just hurt security, which is something else I care about.

We all have to make our own decisions about what to purchase based on the information available to us. That is why having such information is so important. If you value repairability more than anything, you should probably get a Framework. If you value security above all, you should get a Precursor device. If you want a trustable machine that's still high performance, you should get a Mac. If you want to run Windows games, you should get a gaming PC. If you value your freedom... there isn't anything truly free out there. RYF machines certainly aren't it, nor more free than many others by practical measures, nor transparent about their design.

Hence why I criticize the program. It's not achieving anything positive. It's just a feel good thing; the FSF says it respects my freedom so I can feel good about being Free™ while running more proprietary firmware than many other off the shelf machines.

Just to put things into perspective, I believe Google have done more for computing device freedom than the FSF, because the Chromebook team is notoriously pretty much the only large team which actually pushes for open source everything pretty hard, and they're important enough that some vendors listen, and they have the money to develop things themselves. For example, if you look for an open boot/OS stack for the Tegra X1, the closest you're going to get is the Chromebook Pixel's. Only the RAM training blob is closed source (and there is a reverse engineered replacement these days). Everything from the low level bootloader to the GPU drivers are open. This is no thanks to Nvidia - for pretty much all other customers they offer proprietary bootloaders. Also, I'm pretty sure some Chromebooks even have open source EC firmware, which those ThinkPads the FSF loves so much don't.

Look, don't take my word for it - take the word (and more importantly, the reasoning) of the guys behind the Novena open laptop: https://www.bunniestudios.com/blog/?p=5706

also i am confused why this issue isnt being taken with the hardware manufacturers? if i purchased their product, and if their user license did not forbid me from using linux-libre, and if this update is absolutely vital for my safety, then it makes much more sense to take issue with the manufactures. they should open source the update in this case

You can't even argue that it is a difference of being stored in ROM vs. RAM because the existence of patches means that microcode is upgradeable.

You're not sacrificing security, you're making a tradeoff.

If I update my CPU microcode to something I can't check myself, I'm explicitly choosing to trust my CPU provider, under the assumption that the risk of a microcode-based attack from my CPU provider is smaller than the risk of a cpu bug-based attack by an unknown attacker.

If you don't trust your CPU provider then you have zero security from them already. Even if the entire design of the CPU is open-source. https://www.bunniestudios.com/blog/?p=5706

You are already running CPU microcode that can't be checked when you are running Guix on x86. That ship sailed when you decided to use x86.

I personally think the correct criteria is that of security boundaries and change control. If I've got a graphics card with proprietary code (regardless of whether its in ROM or loaded into RAM), with a proper IOMMU, the attacks it can perform on me are limited (eg TEMPEST). The video card itself is not Free or secure, but it's unfortunately something I have to use to interface with my Free/secure computer, just like my keyboard with its proprietary firmware. And as long as I can load any version of firmware onto that video card, then I retain administrative control where the manufacturer can't revoke functionality after I've purchased it.

Disk drives with proprietary software (which is all of them) are not an attack vector, because a drive should only ever be seeing encrypted data to begin with (eg LUKS).

A network card is a bit more worrisome with its direct network access (ie backhaul), but a Free/secure design shouldn't be trusting the network either (unless you have Free/secure switches), so this does not meaningfully change your security properties.

Obviously the above assumes Free/secure drivers, because drivers are running inside the security boundary of the OS.

CPU masks and microcode run afoul of my strict criteria, but are practically inescapable. Proprietary masks/microcode are required for every amd64 system (correct me if I am wrong), so it makes sense to say you have a Free/secure amd64 modulo those proprietary bits (as say Libreboot already does). And with so few versions of CPU microcode, the question of whether to trust a given microcode update is equivalent to whether to trust a given newly released CPU, and shouldn't be viewed as a software Freedom issue.

Do you have a better example?

Stallman personally refused to certify bunnie's Novena laptop (a fully open hardware and software laptop) as "Respects your Freedom" because there were no free drivers for the GPU, and although it wasn't going to ship with GPU acceleration (that's optional anyway), Stallman said users might be "tempted" to install the proprietary blob. Instead he suggested it might be possible to get the manufacturer to cripple the GPU (permanently fuse it off of existing chips that already have it), and then that could be RYF-certified.

bunnie gave up on that, but had he actually shipped a crippled FSF-approved version... a few years later, open drivers for that GPU were developed, so that would've made the regular version certifiable, and everyone who bought the "respects your freedom" version would've been left with needlessly crippled hardware. But the FSF insists this is the way to go.

Meanwhile, they're endorsing "Respects Your Freedom" Bluetooth dongles that have about half a megabyte of proprietary firmware in ROM.

So ... FSF made the right call? What is the point of the certification of a device if there are no drivers for it.

It would be a kinda good idea to have a "rms would almost use this" sticker they could hand out, though.

Looking at: https://ryf.fsf.org/categories/laptops

There is a sorry collection of refurbished laptops.

This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]:

Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult.

If you can make the deblobbing script leave an escape hatch for users to load their own blobs, at their option, I'm sure the pull request would be well-received.

[0] https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-lib...

> Another significant change in this release is that it was pointed out that there were error messages in Linux suggesting users to update x86 CPU microcode. Since such microcode is non-Free Software, such messages don't belong in GNU Linux-libre.

That reads very much as "we don't want to encourage users to consider updating microcode". Your argument also seems unlikely since distros ship the microcode as an extra package that gets picked up by the kernel, so clearly the ability to not upload microcode if the user doesn't provide it is there. (It makes sense that is that way and a different situation than the drivers your link discusses, since the device runs without a microcode update, whereas peripherals that need blobs often won't run at all without them)

http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...

Grep for "Do no recommend non-Free microcode update" [sic].

The actual censoring patterns are here:

http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...

Grep for "arch/x86/kernel/apic/apic.c" to find some of them.

Here's the Debian package for the Intel microcode, for example:

https://packages.debian.org/bullseye/intel-microcode

Debian hides it away in their "non-free" repo but it's in the default install in many other distros.

    dmesg | grep "microcode updated early to"

Also, these packages allow vendors to keep quiet about security issues, because they can silently fix them in the next update.

If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

Typically packages including microcode behave the same way - prompt to update the package, no prompt to implement that update (replace individual files).

It's all a big lie. There's proprietary firmware everywhere. The FSF just doesn't want users to know about it, so they can live happily in their blissful ignorance believing they are freer than everyone else.

"arbitrary political view"

there's a difference, it matters.

Political views have parties and parties have supporters. FSF is more like a cult that has followers.

How else do you explain their rejection to include Debian as a fully free distro?

https://www.gnu.org/distros/free-system-distribution-guideli...

Specifically, "A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so."

This is a political stance based on rational arguments and has nothing to do with religion.

I wish both of them directed their efforts towards more pragmatic problems, like making their software more accessible. In the rest of the world, freedom is usually a function of accessibility.

Make a fork of their code with your preferred changes. The world will be improved and people who agree with you will be happy.

BTW same thing is with Nix: you may not like the choices of NixOS but still enjoy most of the advantages Nix has to offer.

Part of allowing for informed choices is about raising awareness, for instance by explaining why some WiFi devices won't work out of the box (which is really the only practical issue one might stumble upon): https://guix.gnu.org/manual/en/html_node/Hardware-Considerat...

your statement is misleading

why did you add "unless you can't see them"

did FSF said binary blobs you can't see are not bad? Seems opposite from what FSF would do