You're ignoring the crux if the issue. This isn't about running proprietary microcode or not. All x86 Guix users are running proprietary microcode. Period. This is a fact, whether they know about it or not. It's not optional. Would it be great if they didn't have to? Sure. But that's not the world we live in.
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.
>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
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".
* 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?
And if free software existed for any of those chips, FSF would require it. If there is any room for consistency in the criteria, it would be to deal with the fact that some of the computers have less nonfree firmware than others. Eg: the raptor computer has far less than the x200.
> 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
> doing what they believe is best for software freedom
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.
arguing that FSF is some crazy sect or a religion is certainly not constructive to improving what they do
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
See, the funny thing is that Apple's M1 devices are less backdoorable than the FSF's "Respects your Freedom" laptops. That's because unlike those obsolete laptops, Apple's designs actually firewall off all the blobs and coprocessors using IOMMUs, and those IOMMU configurations are introspectable by system software so it can confirm they are correct and not granting too much access. That means if you boot Linux on an M1, and you check the IOMMU configs (most of which are not locked, but those which are are readable), you can say "yup, this isn't backdoored". There is also no nested virtualization support on those machines, and the design of ARM virtualization makes it impossible to "hide" a secret backdoor hypervisor. There is also no ME or any other hyper-privileged software. On top of that, the fact that Apple uses code signing for their entire boot stack means that only they can theoretically (though as I said, in practice detectably) backdoor your laptop - that's much better than the RYF laptops, which have no security and therefore anyone in the supply chain can backdoor them. Oh yeah, and all the post-boot blobs on M1s are stored in the filesystem or readable Flash memories, so you can actually audit them, unlike all those microcontrollers with LPC access to all system RAM on the RYF machines. That's just nasty, the perfect design for an invisible backdoor.
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.
>FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations
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
> 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
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.
fair enough. i value your opinion on the matters of hardware security and i am definitely not going to pretend i am an expert. i know you know your stuff. my point is that fighting for free software and fighting for security (software or hardware) can diverge
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
> only they can theoretically (though as I said, in practice detectably) backdoor your laptop
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 product-security@apple.com 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.
> 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.
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.
Leaving aside the fact that binary blobs already existing in x86 processors doesn’t mean much for users because they can’t help that - I mean, GNU existed before Linux, and only became a completely free operating system when Linux was released, so it’s not like the position of the GNU project was to completely rule out the possibility of running any software or hardware if there was a sniff of non-free software within a 5km radius …
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.
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.