3 ms·

cpu_rec: https://github.com/airbus-seclab/cpu_rec https://github.com/airbus-seclab/cpu_rec > However, you seem to be unfairly criticizing Purism for obfuscatio

cpu_rec: https://github.com/airbus-seclab/cpu_rec https://github.com/airbus-seclab/cpu_rec > However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules The question is why are they doing that? Why are they pandering to a program which ends up encouraging less free devices? RYF is completely broken and does not deliver what people think it does, and the FSF have shown zero interest in educating users about what it means and doesn't. It is a feel-good program that actually hurts the ecosystem behind the scenes. Why is Purism lending it legitimacy by attempting to get certification? They should've done what bunnie did after Stallman showed up with that crazy "fuse the GPU off" idea: give up on this nonsense and focus on delivering a device as free as possible, instead of wasting engineering time pandering to a program that isn't helping anyone. > It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5. Indeed, and this is the crux of the problem: 100% libre modern hardware is impossible in the current world, but the FSF and people who buy in to their tactics keep pretending it is. That there is some magical line that denotes a device as "freedom-respecting" and they can just put things in that bucket and slap a sticker on it and sell it to all those freedom fanboys. This encourages further ignorance: users don't have to think about practicalities such as what security risks are actually present or what the lack of source code for some components might do to affect things they might practically want to do. They don't have to think about whether things are signed or validated, or how to verify that they are running software that is at the very least trusted to be a widely available build, or anything like that. They just see "no blobs in my filesystem!" "freedom!" and declare that device as a Friend of Free Software. And then they extrapolate from that a bunch of properties that are absolutely not implied, around privacy and security and more. > It seems to me that Purism did the best that it could with an impossible situation, and if anybody should be criticized it is the FSF for not acknowledging how modern hardware actually works. Purism did a decent job with the hardware; the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem. > Another thing that I find problematic is your argument that 58 KB of DDR4 timer training blobs represent a security threat in the real world Oh, they absolutely don't. In practice they don't; they also do not present any practical restriction on freedom. Even if the training code were open, I bet there isn't a single person who would ever modify it on a shipping device (especially one with soldered RAM). That's the kind of thing you need 6-figure test equipment to validate properly, and there is no reason to go mucking with it for any end user of the hardware. It existing as a blob causes zero reduction in practical freedom for users, because source code for it would only give you theoretical freedom that nobody wants or needs to exercise. But you see, the entire FSF culture isn't about practicalities. That's the whole problem with it. It is about platonic ideals and philosophical arguments, and completely eschews looking at how real people are affected by software being open or closed. And from that point of view, > and make the Librem 5 no different than an Apple device with an M1 processor They indeed make it no different, because in both cases you're running blobs on boot, and you're in the same practical situation from an absolutist point of view, modulo the FSF's backdoor arguments. > which is literally a black box. How so? The i.MX8M is also a black box by that token; it's a pile of silicon. Sure, it may be (partially - those SoC programming manuals always have censored parts) documented, but it's not open hardware. You can't know what it does precisely. You can't prove the absence of a backdoor any more than you can with the M1. > Forget the fact that the L5 is the first phone to have free/open source schematics I have schematics for some of my M1 Macs. Sure, they leaked and were not willingly published... but in the end, I have them and can look things up in them. So for analysis/educational intents and purposes, I'm in a similar situation as you are with the L5. (Of course it makes a difference in corporate goodwill that Purism published them deliberately; I'm just pointing out that you're limited to that aspect, since at the end of the day, we both have schematics for our devices, so we're both in the same situation as far as being able to understand them). > and everything is running free/open source drivers. We're working on that for the M1. You can run Linux on the M1 today with fully free/open source drivers for most critical parts of the hardware. This blog post has a table of hardware support and upstreaming status: https://asahilinux.org/2021/12/progress-report-oct-nov-2021/ https://asahilinux.org/2021/12/progress-report-oct-nov-2021/ Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally. I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020. And that was working from scratch, on an unknown SoC, reverse engineering everything, having to make more intrusive patches to Linux because this SoC is quite "special", having to write our own pre-bootloader from scratch, etc. A year after release, we have a bunch more hardware working and on the way to upstreaming, including sound on the Mac Mini, I2C, SPI, NVMe, keyboard/trackpad on the laptops, USB and USB-C, power management, basic screen/display controller support, Wi-Fi (including on prior Macs going back to 2017), and support for 9 distinct hardware platforms including the just-launched M1 Pro and M1 Max models, which were already at feature parity a few weeks later. Given all that, I'd say we're doing a lot better with M1 upstream support with fully free drivers than Purism did, timeline-wise. And we didn't need a SoC programming manual. Maybe it's because we aren't wasting time trying to get RYF certification? :-) Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work. > Think about how much code would be needed to initialize the cellular modem or WiFI and then run a TCP/IP stack to communicate with the outside world. The M1 is in that situation too: Apple's bootloader is bare-bones and doesn't even support USB, let alone networking (by design). The Wi-Fi firmware is larger than the first-stage and second-stage bootloaders put together. The whole thing boots too fast to go around initializing Wi-Fi (just firmware upload and boot takes a few seconds on these modules...) and associating to a network and phoning home. And due to the SoC design, after boot, no proprietary code remains running on any secondary core with the ability to take over the system; all auxiliary cores running firmware are sandboxed behind IOMMUs, and the main CPU does not have the ability to run a secret supervisor/hypervisor under the OS (it can run a hypervisor but that cannot be done surreptitiously and silently; the guest knows). And of course, given how Apple is constantly under attack by nation-state-sponsored entities like NSO, they have every incentive to fix security problems and build systems that are very difficult to compromise. To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might), nor does it make any attempt at being secure against physical access attacks (e.g. evil maid). The M1 does. I can install my own Linux bootloader, which requires entering my machine owner credentials, and know that nobody else can take over the device without wiping storage entirely via DFU mode, even if they have physical access, at least not without Apple's help (and even then there's ways of hardening that, but we're still working on the details). And I still don't have to delegate all my security to Apple; I can still use full disk encryption and know that even if they reboot the device to take over the boot process, they won't be able to get at my data. This is not to say the M1 is a security panacea and the L5 is terrible. They each have their pros and cons. Some people might prefer one, some people might prefer the other. That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.

seba_dos1 5y ago
> Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work. For the record - we have some changes for this driver in our downstream tree waiting to get upstreamed (some may need to be reworked though): https://source.puri.sm/Librem5/linux-next/-/commits/next/byzantium/drivers/usb/typec/tipd https://source.puri.sm/Librem5/linux-next/-/commits/next/byz...
Fnoord 5y ago
I wanted to add that I noticed this kind of all or nothing (or perfionist, or black and white thinking) all the time in the free software community, the vegan community, as well as the Fairphone community (who have made 4 iterations of a fair smartphone (fair being for environment and workers), as well as 3 iterations on a repairable, modular smartphone). They innovated long term support on smartphones for 3 iterations, and the competition is slowly but surely getting better there as well. I get the frustrations behind it, but its harmful. Its unfair to advocate for others to not use/buy a device because it doesn't fit their perfectionist specifications, while the project made a substantial effort and should be judged on the incremental improvement instead. More so, when they its a unique project which is far ahead of the competition. What happened though, with regards of that extra layer, is akin to the glue Nvidia uses for their proprietary driver. Its akin to greenwashing. Its dishonest, and unnecessary. Its a marketing ploy. Yes, we should criticize companies for such behavior. No, it does not mean the entire product (or company) is terrible.
amosbatto 5y ago
The RYF certification program is based on Richard Stallman's outdated idea that hardware shouldn't be changed and software is anything that can be changed or updated after the device is produced. Anyone who looks at how x86 processors use microcode updates and the security threats with Meltdown and Spectre knows that a modern x86 PC needs to get microcode updates. Even worse is the fact that building a device to comply with RYF actually makes it more difficult to work on freeing the blobs. In the case of the Librem 5, you have to write to the SPI NOR Flash chip to replace the 4 blob files, rather than simply changing the files stored on in the /lib/firmware directory. However, there are people in the FSF who recognize this. See the comments of Leah Rowe (the Libreboot maintainer) about the problems with the RYF criteria: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-01/msg00019.html https://lists.gnu.org/archive/html/libreplanet-discuss/2022-... (read her comments in the libreboot policy she linked to) I have also criticized the binary nature of RYF certification and suggested that it either needs to move to a category based system: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/17 https://forums.puri.sm/t/does-respects-your-freedom-certific... or a number score system: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/20 https://forums.puri.sm/t/does-respects-your-freedom-certific... > That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion. I largely agree that RYF has problems, but it isn't useless, since it does tell people that they can install a new OS or upgrade it without having to deal with proprietary blobs. However, if people want to upgrade the firmware, a RYF device makes that very inconvenient, because you can't just stick the new firmware in the /lib/firmware directory, but have to follow an awkward procedure to upgrade each component's proprietary firmware, and the RYF rules are unclear about whether those upgrades are even allowed. I have written repeatedly to the FSF asking for clarification on whether proprietary firmware can be upgraded under the RYF rules, and I have never received an answer. See: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484 https://forums.puri.sm/t/does-respects-your-freedom-certific... It's worth mentioning that Purism intends to provide firmware updates for the L5 and has already posted instructions upgrading a couple components: * Texas Instruments TPS65982 USB Type-C and Power Delivery controller: https://source.puri.sm/Librem5/firmware-tps6598x-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree * Silicon Labs RS9116 WiFi/Bluetooth: https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/redpine-firmware-nonfree However, I would agree that the RYF certification isn't useful for distinguishing whether the PinePhone's firmware is more free than the Librem 5's firmware. In fact, it can be argued that the PinePhone has inspired a lot of community work to replace parts of the EG25-G modem's proprietary firmware, so the PinePhone will potentially have a freer modem than the Librem 5. RYF also has nothing to say about the freeness of your hardware. For example, the MNT Reform provides all its sources for the design of the hardware, so anyone can legally make it, whereas Purism has released the PDF files for the L5's schematics, and the STL files for its case, but won't release the original design files for the boards and case until it recovers its development costs. PINE64 releases the board schematics as PDF files, but they have a normal copyright, so no one can legally reuse or modify them. If you want to do board repair, however, you need to know the placement of each component on the board, and neither Purism nor PINE64 have released board views, whereas board views are leaked for most Apple devices. > the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem. It seems that you want to throw the baby out with the bath water. In my opinion, the basic goals of the FSF need to be supported. The problem is the strategy that the FSF uses to reach those goals and its specific policies. I want to see a world where ordinary people can control the technology that they rely on, rather than technology being used as a means to control people. As I see it, we got lucky with the x86 architecture, because Intel and AMD used a standard booting procedure which wasn't locked, so it was possible to install our own OS on almost any PC in the past, but as PCs move to ARM, I fear that every company is going to copy Apple in designing their own ARM processors for PCs, which have custom booting procedures. Maybe Qualcomm, Samsung, MediaTek, UNISOC and all the rest who are reportedly designing custom ARM processors (Google, Xiaomi and Oppo) will release their files or share info, but I suspect that many PCs in the future will be like the Apple A-series processors where we can't install Linux. In my opinion, the best strategy to avoid this dark future is to support the device makers and component makers who support free/open source software, rather than continuing to buy products from companies that don't share our goals. Apple sued Corellium (and thankfully lost in court), which is a good indication of Apple's attitude toward its users. When we buy Apple products, we give more resources to a company that is openly hostile to users being able to control their own hardware. While I have specific criticisms of the RYF, I want the RYF certification program to be reformed so it is useful in the real world, because I do think that people who care about FOSS should be giving their money to companies that support their goals, because that is the best way to create a sustainable industry in the long term that respects user rights and are willing to work with the community. Giving our money to companies like PINE64, Purism, Lulzbot, OLIMEX, Raptor Systems, Arduino, MNT, etc. helps build up our leverage, because these companies will have more power to make demands of component suppliers. NXP has positioned itself as the best ARM manufacturer for the Linux community (ahead of Rockchip), whereas I rank Apple as the second worst (although today I would now place it as the third worst ahead of UNISOC and HiSilicon). See: https://forums.puri.sm/t/concerns-about-the-security-risk-of-chinese-chips/10358 https://forums.puri.sm/t/concerns-about-the-security-risk-of... I know that the Librem 5 doesn't have great performance compared to a phone based on an A13 or Snapdragon 888 (see my benchmarks: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and-pp/ https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...), but I bought the phone anyway, because I know that Purism went out of its way to select component manufacturers who support FOSS. NXP makes commits to mainline Linux to support its i.MX processors, and releases documentation to the community without NDA's. Silicon Labs (formerly Redpine Signals) releases the drivers for its WiFi/Bluetooth chips under the GPL 2 and altered its firmware at the request of Purism so it didn't have to load the firmware from the main Linux file system. By giving money to Purism, NXP and Silicon Labs, I'm helping to build up a better supply chain, so there is more hope of getting hardware in the future that respects our digital rights.

seba_dos1 5y ago

> Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work. For the record - we have some changes for this driver in our downstream tree waiting to get upstreamed (some may need to be reworked though): https://source.puri.sm/Librem5/linux-next/-/commits/next/byzantium/drivers/usb/typec/tipd https://source.puri.sm/Librem5/linux-next/-/commits/next/byz...

Fnoord 5y ago

I wanted to add that I noticed this kind of all or nothing (or perfionist, or black and white thinking) all the time in the free software community, the vegan community, as well as the Fairphone community (who have made 4 iterations of a fair smartphone (fair being for environment and workers), as well as 3 iterations on a repairable, modular smartphone). They innovated long term support on smartphones for 3 iterations, and the competition is slowly but surely getting better there as well. I get the frustrations behind it, but its harmful. Its unfair to advocate for others to not use/buy a device because it doesn't fit their perfectionist specifications, while the project made a substantial effort and should be judged on the incremental improvement instead. More so, when they its a unique project which is far ahead of the competition. What happened though, with regards of that extra layer, is akin to the glue Nvidia uses for their proprietary driver. Its akin to greenwashing. Its dishonest, and unnecessary. Its a marketing ploy. Yes, we should criticize companies for such behavior. No, it does not mean the entire product (or company) is terrible.

amosbatto 5y ago

The RYF certification program is based on Richard Stallman's outdated idea that hardware shouldn't be changed and software is anything that can be changed or updated after the device is produced. Anyone who looks at how x86 processors use microcode updates and the security threats with Meltdown and Spectre knows that a modern x86 PC needs to get microcode updates. Even worse is the fact that building a device to comply with RYF actually makes it more difficult to work on freeing the blobs. In the case of the Librem 5, you have to write to the SPI NOR Flash chip to replace the 4 blob files, rather than simply changing the files stored on in the /lib/firmware directory. However, there are people in the FSF who recognize this. See the comments of Leah Rowe (the Libreboot maintainer) about the problems with the RYF criteria: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-01/msg00019.html https://lists.gnu.org/archive/html/libreplanet-discuss/2022-... (read her comments in the libreboot policy she linked to) I have also criticized the binary nature of RYF certification and suggested that it either needs to move to a category based system: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/17 https://forums.puri.sm/t/does-respects-your-freedom-certific... or a number score system: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/20 https://forums.puri.sm/t/does-respects-your-freedom-certific... > That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion. I largely agree that RYF has problems, but it isn't useless, since it does tell people that they can install a new OS or upgrade it without having to deal with proprietary blobs. However, if people want to upgrade the firmware, a RYF device makes that very inconvenient, because you can't just stick the new firmware in the /lib/firmware directory, but have to follow an awkward procedure to upgrade each component's proprietary firmware, and the RYF rules are unclear about whether those upgrades are even allowed. I have written repeatedly to the FSF asking for clarification on whether proprietary firmware can be upgraded under the RYF rules, and I have never received an answer. See: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484 https://forums.puri.sm/t/does-respects-your-freedom-certific... It's worth mentioning that Purism intends to provide firmware updates for the L5 and has already posted instructions upgrading a couple components: * Texas Instruments TPS65982 USB Type-C and Power Delivery controller: https://source.puri.sm/Librem5/firmware-tps6598x-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree * Silicon Labs RS9116 WiFi/Bluetooth: https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/redpine-firmware-nonfree However, I would agree that the RYF certification isn't useful for distinguishing whether the PinePhone's firmware is more free than the Librem 5's firmware. In fact, it can be argued that the PinePhone has inspired a lot of community work to replace parts of the EG25-G modem's proprietary firmware, so the PinePhone will potentially have a freer modem than the Librem 5. RYF also has nothing to say about the freeness of your hardware. For example, the MNT Reform provides all its sources for the design of the hardware, so anyone can legally make it, whereas Purism has released the PDF files for the L5's schematics, and the STL files for its case, but won't release the original design files for the boards and case until it recovers its development costs. PINE64 releases the board schematics as PDF files, but they have a normal copyright, so no one can legally reuse or modify them. If you want to do board repair, however, you need to know the placement of each component on the board, and neither Purism nor PINE64 have released board views, whereas board views are leaked for most Apple devices. > the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem. It seems that you want to throw the baby out with the bath water. In my opinion, the basic goals of the FSF need to be supported. The problem is the strategy that the FSF uses to reach those goals and its specific policies. I want to see a world where ordinary people can control the technology that they rely on, rather than technology being used as a means to control people. As I see it, we got lucky with the x86 architecture, because Intel and AMD used a standard booting procedure which wasn't locked, so it was possible to install our own OS on almost any PC in the past, but as PCs move to ARM, I fear that every company is going to copy Apple in designing their own ARM processors for PCs, which have custom booting procedures. Maybe Qualcomm, Samsung, MediaTek, UNISOC and all the rest who are reportedly designing custom ARM processors (Google, Xiaomi and Oppo) will release their files or share info, but I suspect that many PCs in the future will be like the Apple A-series processors where we can't install Linux. In my opinion, the best strategy to avoid this dark future is to support the device makers and component makers who support free/open source software, rather than continuing to buy products from companies that don't share our goals. Apple sued Corellium (and thankfully lost in court), which is a good indication of Apple's attitude toward its users. When we buy Apple products, we give more resources to a company that is openly hostile to users being able to control their own hardware. While I have specific criticisms of the RYF, I want the RYF certification program to be reformed so it is useful in the real world, because I do think that people who care about FOSS should be giving their money to companies that support their goals, because that is the best way to create a sustainable industry in the long term that respects user rights and are willing to work with the community. Giving our money to companies like PINE64, Purism, Lulzbot, OLIMEX, Raptor Systems, Arduino, MNT, etc. helps build up our leverage, because these companies will have more power to make demands of component suppliers. NXP has positioned itself as the best ARM manufacturer for the Linux community (ahead of Rockchip), whereas I rank Apple as the second worst (although today I would now place it as the third worst ahead of UNISOC and HiSilicon). See: https://forums.puri.sm/t/concerns-about-the-security-risk-of-chinese-chips/10358 https://forums.puri.sm/t/concerns-about-the-security-risk-of... I know that the Librem 5 doesn't have great performance compared to a phone based on an A13 or Snapdragon 888 (see my benchmarks: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and-pp/ https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...), but I bought the phone anyway, because I know that Purism went out of its way to select component manufacturers who support FOSS. NXP makes commits to mainline Linux to support its i.MX processors, and releases documentation to the community without NDA's. Silicon Labs (formerly Redpine Signals) releases the drivers for its WiFi/Bluetooth chips under the GPL 2 and altered its firmware at the request of Purism so it didn't have to load the firmware from the main Linux file system. By giving money to Purism, NXP and Silicon Labs, I'm helping to build up a better supply chain, so there is more hope of getting hardware in the future that respects our digital rights.