6 ms·

https://ryf.fsf.org/products/TET-BT4 https://ryf.fsf.org/products/TET-BT4 No mention of the half megabyte of proprietary Bluetooth stack firmware (with signifi

https://ryf.fsf.org/products/TET-BT4 https://ryf.fsf.org/products/TET-BT4 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 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?

medo-bear 5y ago
their certification process as oitlined on https://ryf.fsf.org/about/criteristates https://ryf.fsf.org/about/criteristates: 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
- marcan_42 5y ago
  > 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.
  - medo-bear 5y ago
    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
    - marcan_42 5y ago
      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.
r283492 5y ago
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.

medo-bear 5y ago

their certification process as oitlined on https://ryf.fsf.org/about/criteristates https://ryf.fsf.org/about/criteristates: 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

marcan_42 5y ago
> 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.
- medo-bear 5y ago
  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
  - marcan_42 5y ago
    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.

r283492 5y ago

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.