Purism suffered a distributed-denial-of-service (DDoS) attack on July 29, 2023, which took down their site, as they explained on their Matrix channel and forum (when the site came back online). See: https://forums.puri.sm/t/sites-down-no-comms/21000/3
It is likely that someone who owns a botnet saw Rossmann's criticism of Purism and decided to that the company deserved to be attacked, which is a really rotten thing to do, because then people assume that Purism is hiding something.
I agree that Purism should have refunded the cancelled orders, but calling the company a "scam" is way over the top, considering the huge amount of dev work that Purism has done on mobile Linux and the Phosh interface. I own both the Librem 5 and Librem 5 USA and the company is definitely not a "scam".
I did see that on the forums, I guess some more transparency on that would have been helpful, since it seems they only told people well after the fact.
At the very least not responding to customers is very bad for business, I'm not sure on what basis that Rossman is considering them a scam, but my basis is this, the (possibly illegal under US securities laws) "Investment Opportunity" they've been bugging people about:
I am a happy owner of a Librem laptop and very much want them to succeed as a company despite all this (assuming that they can get new leadership), but that can't happen if they can't simply be honest with their customers. They're doing something extremely ambitious so it's OK if there are setbacks but they need to be transparent about that. They need to be honest about the setbacks in getting the Librem 5 shipped for people that have been waiting literally years for a phone, and not change refund policies after the fact without clearly communicating it. Trying to silence critics via toxic positivity also isn't helping.
In the investment email, they say that they expect to ship both a Librem 11 tablet and Librem 16 laptop sometime this year, that also seems naively optimistic at best and extremely dishonest at worst. As much as I'd love that to happen and would even consider buying a Librem 11 in spite of everything, if they're struggling this badly to ship a phone they've been working on for years, I don't know how they expect people to believe that they can ship two completely new products in that amount of time.
> More developers are familiar with Android than the desktop Linux software stack. More work goes into it. Far more apps are written for it, and that includes a very active open source app ecosystem.
The problem is that the Android app ecosystem has a very large number of apps which are based on collecting users' personal information and violating people's privacy, and it is hard for a normal user to avoid all the spyware and malware in Android. In my experience using CyanogenMod/LineageOS and the F-Droid repo since 2015, I inevitably fall back to installing some proprietary apps when using AOSP-derivatives, whereas my PinePhone and Librem 5 USA only have FOSS apps and drivers installed on them. If the goal is to use FOSS as much as possible, you are better off buying a Linux phone in my opinion.
By the way, one of the apps that I helped develop is on F-Droid (https://f-droid.org/en/packages/com.ketanolab.nusimi/ ) and I have given workshops on how to install LineageOS on phones, so I speak as someone who tries to promote the use of FOSS on Android phones, but the phone industry does put up a lot of barriers to make it difficult to install AOSP-derivatives.
> GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. We can support pretty much any mobile device with alternate OS support since any serious one will have AOSP support. Most devices have lackluster security and don't meet our requirements.
The problem is that Google only sells Pixels in a very limited number of countries. Whereas Purism offers free worldwide shipping for the Librem 5, the Pixel 6 is only being sold in 8 countries (Australia, Canada, France, Germany, Japan, Taiwan, UK, USA), so your security requirements exclude over 90% of the world's population from being able to use GrapheneOS. Plus, many people don't want to financially support a company like Google which is based on Surveillance Capitalism.
> We're working with a hardware vendor to get a non-Pixel phone actually meeting reasonable security requirements.
Good to hear. I look forward to seeing it.
> Librem 5 has a bunch of components where they are not shipping updates.
Not true. Purism has promised to provide updates to the proprietary firmware on the Librem 5, and already provides instructions for how to update the firmware on the WiFi/BT and USB controller. See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
> It has a bunch of poorly secured and insecurely configured legacy hardware often without proper updates available
What are you talking about? Purism purposely designed the Librem 5 to avoid planned obsolescence, so it looked for component suppliers who support their hardware for a long time. For example, NXP guarantees that that it will provide updates for the i.MX 8M Quad for 15 years (Jan. 2018 - Jan. 2033). See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
In contrast, Google only promises to provide 3 years of OS updates and security updates for the Pixel 3/4/5, and 3 years of OS updates and 5 years of security updates for the Pixel 6. Qualcomm announced in Dec. 2020 that it will support its Snapdragon processors (which are used in Pixel devices) for 3 years of Android updates and 4 years of security updates.
Linux phones like the Librem 5 and PinePhone use separate components which are supported for many years by the manufacturers, whereas most Android phones (like the Pixels) use integrated mobile system-on-chips which are only manufactured for 1-2 years and only supported for 3-4 years by the manufacturer. Because Linux phones use components with long-term support by the component suppliers, the Librem 5 is the first phone to be sold with the guarantee of lifetime software updates, and PINE64 promised to manufacture the PinePhone for 5 years, which is longer than any other smartphone ever sold.
> components that are not properly isolated via IOMMU,
The Librem 5 doesn't need an IOMMU, because it uses separated components, and it uses serial buses (USB 2.0/3.0, SDIO, I2C and I2S) that don't allow direct memory access, so there is absolute no chance of the WiFi/BT, cellular modem, GNSS and USB controller being able to access the RAM or the SoC's cache. Unlike the Snapdragon processors in Pixels whose hardware is essentially a black box, we can independently verify by looking at the open source schematics that direct memory access is not possible in the Librem 5.
> but there are years and years of tons of important privacy/security work done in a systemic way across hardware/firmware/software which are missing there before worrying about stuff like that.
If you are talking about kernel hardening and running each app in its own sandbox with its own UID, then I would agree that Android/AOSP has more security features than Debian/PureOS, but the problem with your argument is that you are ignoring the fact that a mountain of spyware and malware has been created for the Android platform and users have to be very vigilant to not install any of it. According to AV-TEST, 3.38M pieces of malware and 3.18M potentially unwanted apps (mostly spyware) were created for the Android platform in 2021, whereas it is unlikely that any of that garbage will get into the Debian->PureOS repos to ever effect users of the Librem 5. Linux users rarely install anything from outside their distro's repo, whereas I often find myself installing apps whose code I can't verify when I use AOSP-derivatives because I can't find all the apps that I need in F-Droid.
Yes, Android/AOSP does have a lot more security built into its design than Debian->PureOS, but it is based on a model of letting all sorts of unverifiable and dangerous code run inside it. For more on the Librem 5's security, see: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
> Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options
Care to provide any evidence to prove that Purism or its employees are "spreading tons of misinformation and outright lies about the mainstream options"?
I don't see what you're doing as engaging in good faith, and I don't see any use in further discussion. Seeing the same inaccurate talking points over and over attacking GrapheneOS only makes us see Purism and their community as increasingly hostile and malicious. Please keep in mind that I'm only replying here because your community started attacking GrapheneOS. You aren't going to achieve your goal of promoting their products by having me write up a bunch of responses to debunk misinformation. Due to the importance of reusing work, the inevitable result will be that I'll collect it all into an article to post as part of https://grapheneos.org/articles/. We'll will simply link to that as our response going forward. Our community will likely spread the article as they do with our other documentation like our FAQ sections and usage guide. The article(s) will be repeatedly expanded to add sections debunking attempts to misrepresent it or to mislead people about the topics.
At the moment, I'm not currently interested in investing the necessary time into writing such as an article. If you're going to post another lengthy problematic reply, that's the medium I'm going to use for my response rather than writing another comment on this platform which few people are going to see, which is not a good use of my time.
> Due to the importance of reusing work, the inevitable result will be that I'll collect it all into an article to post as part of https://grapheneos.org/articles/. We'll will simply link to that as our response going forward. Our community will likely spread the article as they do with our other documentation like our FAQ sections and usage guide. The article(s) will be repeatedly expanded to add sections debunking attempts to misrepresent it or to mislead people about the topics.
Not OP but I did enjoy reading your well-written replies, so I hope they don't get lost with time as only HN comments, and that you're able to carry them forward more effectively to be shared with others.
> If you are talking about kernel hardening and running each app in its own sandbox with its own UID, then I would agree that Android/AOSP has more security features than Debian/PureOS, but the problem with your argument is that you are ignoring the fact that a mountain of spyware and malware has been created for the Android platform and users have to be very vigilant to not install any of it. According to AV-TEST, 3.38M pieces of malware and 3.18M potentially unwanted apps (mostly spyware) were created for the Android platform in 2021, whereas it is unlikely that any of that garbage will get into the Debian->PureOS repos to ever effect users of the Librem 5. Linux users rarely install anything from outside their distro's repo, whereas I often find myself installing apps whose code I can't verify when I use AOSP-derivatives because I can't find all the apps that I need in F-Droid.
Many other people promoting these platforms often talk about the (limited) support for running Android apps. You can choose to use those apps there, just as you can on GrapheneOS, and it does not make sense to claim that availability of apps is a bad thing. GrapheneOS supports nearly every Android app which would run on the stock OS thanks to the sandboxed Google Play compatibility layer feature. Many of our users including make no use of that feature, and it didn't exist before 2021 so our entire userbase before then was happily using it without Play services. There are more users now, but there were still many before, and many are happy using only the open source Android app ecosystem which goes far beyond F-Droid which doesn't even have apps like Signal, Chromium, Brave, Bromite, etc.
You're trying to make this about AOSP vs. a completely insecure software stack but the post is about a phone which is capable of running AOSP and other phones are more than capable of running the desktop Linux stack. It's a red herring, and you're being thoroughly dishonest and manipulative in how you're presenting the app ecosystem considering that there is a far larger open source app ecosystem for AOSP than there is for desktop Linux on mobile... F-Droid has very incomplete coverage of the overall open source app ecosystem and they don't always do a particularly good job maintaining it. F-Droid itself still targets Android 7.1 (API 25).
I'm talking about the fact that this hardware, firmware and software is a decade behind on security and has almost zero systemic privacy/security work across it. You have the privacy and security situation completely backwards. The fact that Purism blatantly lies about many aspects of their hardware, firmware and software also demonstrates that they're a highly untrustworthy vendor. I would trust a company like HTC far more because at least they aren't blatantly lying about the security patch level, openness of the hardware and they aren't covering up security vulnerabilities, weaknesses and the fact that the firmware/hardware is proprietary.
> Yes, Android/AOSP does have a lot more security built into its design than Debian->PureOS, but it is based on a model of letting all sorts of unverifiable and dangerous code run inside it.
I'm not sure why someone would want to place complete trust in thousands of different fragmented projects which have no real isolation and no systemic privacy/security work on the overall OS or across those projects. Many of those projects are unmaintained, and some of them have even shipping malicious changes either unintentionally or intentionally before. You're also trusting the huge amount of packagers for the OS who set up the builds and patches for these projects. There are still closed source apps availability, but open source is not the magical panacea that you present it as and does not infer any inherent privacy/security properties on the software. It doesn't make the developers inherently more trustworthy or ethical either. It's a development approach, which we can both agree is a great approach and enables people to make changes to the software, fork it or attempt to contribute to it upstream.
> Care to provide any evidence to prove that Purism or its employees are "spreading tons of misinformation and outright lies about the mainstream options"?
You've done a great job of doing that yourself by cycling through a whole bunch of inaccurate talking points promoting their products and attacking other projects like GrapheneOS. Most of it comes directly from Purism, and your comment is an extension of their highly underhanded, dishonest and malicious attacks on projects like GrapheneOS to make sure they keep getting their substantial salaries and profit.
> Care to provide any evidence to prove that Purism or its employees are "spreading tons of misinformation and outright lies about the mainstream options"?
Since you're doing that yourself, I don't think engaging with you on the topic is productive. I responded here due to the inaccurate attacks on GrapheneOS from people promoting Purism products. Doubling down on spreading their inaccurate marketing / talking points isn't going to deter us from responding and we're more than happy to post a more detailed response on our site and across platforms. I already gave detailed responses and don't intend to repeat much of what I've already said.
> The problem is that the Android app ecosystem has a very large number of apps which are based on collecting users' personal information and violating people's privacy, and it is hard for a normal user to avoid all the spyware and malware in Android. In my experience using CyanogenMod/LineageOS and the F-Droid repo since 2015, I inevitably fall back to installing some proprietary apps when using AOSP-derivatives, whereas my PinePhone and Librem 5 USA only have FOSS apps and drivers installed on them. If the goal is to use FOSS as much as possible, you are better off buying a Linux phone in my opinion.
There's a far larger and better ecosystem of open source apps for Android than there is for the products that you're marketing, and they can be used on secure devices rather than blatantly insecure ones not even meeting basic standards as I've already detailed in my responses.
> The problem is that Google only sells Pixels in a very limited number of countries. Whereas Purism offers free worldwide shipping for the Librem 5, the Pixel 6 is only being sold in 8 countries (Australia, Canada, France, Germany, Japan, Taiwan, UK, USA), so your security requirements exclude over 90% of the world's population from being able to use GrapheneOS. Plus, many people don't want to financially support a company like Google which is based on Surveillance Capitalism.
Pixels can be purchased internationally. They don't need to be bought from Google. Purism is a company based around spreading misinformation and marketing their products dishonestly which I know people in our community don't want to support. We're not going to support thoroughly insecure devices from a company which is unwilling to even admit to the limitations/weaknesses let alone fixing them and producing something we could ever consider supporting. The experience we had with them is that they only want to use the name of projects like ours to promote themselves as partners without doing anything on their part. They engaged in libel/harassment/bullying targeting our developers in response to us not supporting their phone as a target and explaining why within our community. I see what you're doing here as an extension of their dishonest marketing and inaccurate attacks on other platforms/projects/products. If this is going to be something that's happening regularly, we'll add detailed documentation / articles to our site about the topic to reference so we don't need to keep writing up the same things.
> Not true. Purism has promised to provide updates to the proprietary firmware on the Librem 5, and already provides instructions for how to update the firmware on the WiFi/BT and USB controller.
There aren't full firmware security updates for the Librem 5 and what I said is completely accurate. What's even worse is that they do not ship the incomplete updates that could be available and they did things in a way that makes it impossible to even ship all of those as part of an OS. Please don't claim that my completely accurate description of the situation is not true based on something that's not in any way debunking what I said.
> What are you talking about? Purism purposely designed the Librem 5 to avoid planned obsolescence, so it looked for component suppliers who support their hardware for a long time. For example, NXP guarantees that that it will provide updates for the i.MX 8M Quad for 15 years (Jan. 2018 - Jan. 2033).
They're unable to provide full security updates from day one and the device is already end-of-life in terms of what that means for GrapheneOS. It would have to be marked as end-of-life from day one if we added support for it. We would be unable to declare any Android security patch level for the device due to it not meeting the basic security requirements and not having full firmware security updates available. What I've said is true, and you're just claiming otherwise based on their deliberately very incomplete and misleading marketing.
> In contrast, Google only promises to provide 3 years of OS updates and security updates for the Pixel 3/4/5, and 3 years of OS updates and 5 years of security updates for the Pixel 6. Qualcomm announced in Dec. 2020 that it will support its Snapdragon processors (which are used in Pixel devices) for 3 years of Android updates and 4 years of security updates.
Those are minimum guarantees of full security updates, not end-of-life dates and the number of days you get those for the Librem 5 is ZERO. The only recommended devices for GrapheneOS are the Pixel 6 and Pixel 6 Pro, which means that there is at least 5 years of full security updates for the devices we support. You can see from our site that we continue providing extended support releases which we mark as insecure past the end-of-life of devices. A device is end-of-life as soon as any important component no longer provides the proper monthly security updates. How can we support the Librem 5 even aside from all the missing security features which have already been explained elsewhere, when we would be unable to provide anything close to the March 2022 security update, and would be unable to ship all the updates that are available through the OS?
> Linux phones like the Librem 5 and PinePhone use separate components which are supported for many years by the manufacturers, whereas most Android phones (like the Pixels) use integrated mobile system-on-chips which are only manufactured for 1-2 years and only supported for 3-4 years by the manufacturer. Because Linux phones use components with long-term support by the component suppliers, the Librem 5 is the first phone to be sold with the guarantee of lifetime software updates, and PINE64 promised to manufacture the PinePhone for 5 years, which is longer than any other smartphone ever sold.
This is completely inaccurate. They still use an SoC and the components they've chosen do not provide a longer period of support in the sense that Android expects in order to declare the latest security patch level. Several of their component choices including the radios rule that out, as does the way they are integrated. Your claim of lifetime security updates is completely bogus and demonstrates the extreme lengths Purism goes to in order to mislead people and profit from it. They still need firmware support and all the drivers, etc. still need to be maintained. There's really no point of engaging with people lying through their teeth and pushing all their inaccurate talking points so I'm not going to keep engaging with you much further.
Linux doesn't mean systemd, polkit, glibc, GCC, binutils, GNOME, pulseaudio/pipewire, Wayland/X11, etc. It makes no sense to claim these are Linux phones when the vast majority of smartphones run Linux. It's marketing spin. If you want to call it a GNU/Linux phone, go ahead, but what you're doing is a deliberate attempt at misleading people on their part.
> The Librem 5 doesn't need an IOMMU, because it uses separated components, and it uses serial buses (USB 2.0/3.0, SDIO, I2C and I2S) that don't allow direct memory access, so there is absolute no chance of the WiFi/BT, cellular modem, GNSS and USB controller being able to access the RAM or the SoC's cache. Unlike the Snapdragon processors in Pixels whose hardware is essentially a black box, we can independently verify by looking at the open source schematics that direct memory access is not possible in the Librem 5.
This is not accurate. It still has an SoC with a ton of components aside from the SoC despite your inaccurate claim that it doesn't, and those components still need to be isolated with an IOMMU. The other components which you're talking about using USB are dramatically less isolated than the Qualcomm or Samsung baseband on mainstream devices. You're trying to present something dramatically worse as being better in this regard. Are you trying to claim that the Librem 5 doesn't have components like a GPU and other SoC components? The Librem 5 hardware is also just as much of a black box. It's 100% as proprietary. It does not have firmware or hardware that's any more open and this is a blatant lie. Them marketing the hardware as being more open is thoroughly unethically and dishonest. They've done the same with their laptops and other products, which has done immense harm to projects like Talos actually trying to produce open hardware in any actual sense of the word.
> The Librem 5 hardware is also just as much of a black box. It's 100% as proprietary. It does not have firmware or hardware that's any more open and this is a blatant lie. Them marketing the hardware as being more open is thoroughly unethically and dishonest. They've done the same with their laptops and other products, which has done immense harm to projects like Talos actually trying to produce open hardware in any actual sense of the word.
There is a major difference between the openness of the Librem 5 (L5) vs Android phones. The L5 is the first phone with free/open source schematics (GPL 3.0) for its circuit boards since the Golden Delicious GTA04A4 which was released in Jan 2012. Purism has only released the STL files for the L5's case and the board schematics in PDF, so it would take some work to recreate the original CAD files, but anybody can legally reproduce the hardware in the L5. To find a phone which released its CAD files, you have to go back to the OpenMoko Neo FreeRunner released in June 2008.
Purism has also released the board view images to show where components are placed on the L5's boards. You may be able to find the board view for a few models (such as iPhones), because they get leaked, but as far as I know, no Android phone manufacturer publicly releases the board views of their circuit boards.
If your argument is that the circuit boards don't matter, because most of the functionality is locked up in proprietary chips, then let's look at the chips that Purism selected and see if there's a difference. Qualcomm, MediaTek, UNISOC and Samsung don't release the documentation for their mobile application processors without an NDA, and Apple and Huawei don't release their documentation on their chips to any outside companies as far as I know. In contrast, NXP released 7000 pages of documentation plus their Android and Linux software for the i.MX 8M Quad to anyone who registers on their website. They restrict the security manual to only certain approved people, but everything else can be obtained and NXP has a public forum where anyone can ask questions about their i.MX processors. Likewise, Thales releases the documentation on the PLS8 cellular modem and provides a public forum.
Android phones commonly have a locked bootloader which prevents the user from changing the OS. All Huawei and Apple phones have the bootloader locked. Most Samsung phone require using an unauthorized crack. Motorola and Xiaomi require applying for an unlock code code and waiting up to two weeks for it and using it voids the hardware's warranty. Sony makes it easy but voids the warranty. Google also makes it easy, but won't honor the warranty unless the Pixel is reflashed to the original OS and relocked. In contrast, the Librem 5 has such restrictions.
Another issue is the drivers and kernels. Qualcomm has the best track record of the major mobile SoC manufacturers since it provides public access and the commit record to its kernel source code at Code Aurora, but the community has to take that code and adapt it to work in mainline Linux and it often takes 3 or 4 years to fully support Snapdragons. Samsung has done better in recent years, but MediaTek, UNISOC, Huawei and Apple are horrible. However, NXP is far better than all these since it commits directly to mainline Linux and is willing to work with the community to support its chips.
Purism develops its code in public and encourages its developers to interact with the community. All the firmware in the L5 is proprietary, but it is worth mentioning that Purism is planning on using FOSS firmware in its secondary Cortex processor to control the smartcard reader. Also the OpenPGP specification is open, so anyone can study it.
I would argue that all of these things add up to make the Librem 5 the most open phone that can be bought today (with the PinePhone a close second). I have a problem with some of Purism's marketing, like the "100% made in the USA electronics" slogan for the Librem 5 USA, but you have to look at this in the context of the actual mobile industry and what is possible in the real world. Sure it would be great to have a phone with open hardware chips, but you are talking about hundreds of millions of dollars to develop those chips and paying hundreds of millions more to license the necessary IP, which is totally unrealistic.
> Linux doesn't mean systemd, polkit, glibc, GCC, binutils, GNOME, pulseaudio/pipewire, Wayland/X11, etc. It makes no sense to claim these are Linux phones when the vast majority of smartphones run Linux. It's marketing spin. If you want to call it a GNU/Linux phone, go ahead, but what you're doing is a deliberate attempt at misleading people on their part.
I was simply following the standard convention of saying "Linux" to mean the entire OS that is found in popular distros like Debian, Arch and Fedora, whereas people generally say "Linux kernel" to refer to just the kernel. Saying "GNU/Linux" is problematic because most distros contain software which isn't part of GNU and isn't approved by the FSF, but I will use that term for lack of a better one.
By the way, it is just as problematic to say that GrapheneOS is "Linux" because GrapheneOS is using a kernel which has been substantially modified by Google, and Qualcomm's drivers for the Snapdragon which GrapheneOS uses are only designed to support an Android kernel, not a mainline Linux kernel. GrapheneOS doesn't use mainline Linux kernels and it usually takes 3-4 years for the mainline kernel to fully support new Snapdragons after they are released, so I don't know why you are even bothering to make this argument.
> There's a far larger and better ecosystem of open source apps for Android than there is for the products that you're marketing...
Just to be clear, I'm simply a customer of Purism and PINE64 who owns the Librem 5 USA and PinePhone, so I don't represent these companies and I'm not marketing their products.
I'm not sure whether there is a larger ecosystem of open source apps for Android rather than the GNU/Linux distros that run on the Librem 5 and PinePhone. If we are talking about apps which are designed to run on mobile phones, then you have a point, since it will take a while to adapt all the desktop software to be mobile-friendly, but Kirigami or libhandy/libadwaita is getting added to a lot GNU/Linux desktop software to make it adaptive. Google purposely does not label software with FOSS licenses in the Play Store, so it is hard to count the number of FOSS apps for Android. I count 4472 apps in F-Droid (https://f-droid.org/repo/index-v1.jar), whereas Debian 11 "bullseye" (which is what PureOS and Mobian are based on) has 59,551 packages. I know that not all FOSS apps make it into the F-Droid repo and the Debian repo includges the entire operating system and many of its applications use multiple packages, so we are comparing apples and oranges, but I don't see much evidence that the Android FOSS ecosystem is "larger and better" than the GNU/Linux ecosystem.
I often find that I need to install proprietary apps when using LineageOS because I can't find what I need in F-Droid, whereas I generally don't install proprietary apps in my GNU/Linux systems, so from that point of view, GNU/LInux is "better". Also a sizeable number of the FOSS apps that I encounter in F-Droid contain some code which was originally written for GNU/Linux, whereas I rarely find code in GNU/Linux which was originally written for Android.
> This is not accurate. It still has an SoC with a ton of components aside from the SoC despite your inaccurate claim that it doesn't, and those components still need to be isolated with an IOMMU.
I stated that "the Librem 5 doesn't need an IOMMU" to isolate the WiFi/BT, cellular modem, GNSS and USB controller, but in case you are worried, the i.MX 8M Quad SoC in the Librem 5 does have a Resource Domain Controller (RDC), Arm TrustZone and On-chip RAM (OCRAM) secure region protection, which does isolate the CPU, GPU and VPU. See section "3.2.2.4 Resource Domain Control and Security Considerations" in the "i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual". (NXP requires registration to download the manual.)
> Those are minimum guarantees of full security updates, not end-of-life dates and the number of days you get those for the Librem 5 is ZERO. The only recommended devices for GrapheneOS are the Pixel 6 and Pixel 6 Pro, which means that there is at least 5 years of full security updates for the devices we support.
The GrapheneOS FAQ lists the Pixel 3a released in May 2019 as a "supported" device, but the Pixel 3 released in October 2018 is listed as "end-of-life" because it no longer gets full security updates, so that tells me that most people are using GrapheneOS on devices that have a 3 year lifespan.
I downloaded the Pixel 3a's "bonito" kernel (https://github.com/GrapheneOS/device_google_bonito-kernel) and I see that it is using kernel version 4.9.292. Mainline Linux 4.9.292 was released on 2021-12-08 and 4.9.0 was released on 2016-12-11. Call me crazy but I prefer to use an up-to-date mainline kernel rather than one that is over 5 years old and takes 3 months to get the latest security patches from kernel.org. (To be fair, I should mention that the Librem 5 issn't yet fully supported in mainline Linux, so you can't run the latest mainline kernel on day one of its release, but the Purism devs say that mainline support is coming.)
> Your claim of lifetime security updates is completely bogus and demonstrates the extreme lengths Purism goes to in order to mislead people and profit from it.
Purism says that it went way over-budget trying to develop the Librem 5 and its software, which is why it has been raising its prices. Considering the roughly 20 companies that lost their shirts in the past when trying to develop mobile Linux, it is unrealistic to think that Purism is doing this for profit. (See: https://amosbbatto.wordpress.com/2020/07/17/mobile-linux-tra...)
Granted that NXP will stop providing firmware updates for the i.MX 8M Quad in 2033, and I expect that the firmware updates will end much sooner than that for the RS9116 WiFi/BT, BM818 cellular modem, Tesio-Liv3 GNSS, etc, but there is no reason to not expect lifetime software updates, because the Librem 5 should soon have mainline Linux support. Purism has worked hard to upstream its code changes to parent projects (Linux, wlroots, geoclue, ModemManager, GTK, GNOME libraries, GNOME applications, etc.), so that future releases of these projects should run on the Librem 5 with minimal work. Phosh was designed as a thin overlay on top of standard GNOME libraries and applications (which have substantial support from IBM/Red Hat, SUSE, Canonical and Google) and roughly 176k of the roughly 250k lines of code that Purism has created for the Librem 5 are now incorporated as official GNOME projects. (see: https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr... ) What this means is that it shouldn't cost Purism much to keep providing future software updates. In addition, postmarketOS and Mobian developers are now participating in the development of Phosh which has become the most popular interface among PinePhone users, so even if Purism dies as a company, it is likely that the community will maintain the interface. For more info, see: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
> Purism says that it went way over-budget trying to develop the Librem 5 and its software, which is why it has been raising its prices. Considering the roughly 20 companies that lost their shirts in the past when trying to develop mobile Linux, it is unrealistic to think that Purism is doing this for profit.
The Librem 5 is incredibly low-end hardware with many corners cut being sold for now 1299 USD. You go across platforms marketing their products with thoroughly dishonest claims and spin. It's highly likely that you have a financial stake in the company's products because nothing else would explain your devotion to so thoroughly misleading people and marketing their products across many platforms.
> Granted that NXP will stop providing firmware updates for the i.MX 8M Quad in 2033, and I expect that the firmware updates will end much sooner than that for the RS9116 WiFi/BT, BM818 cellular modem, Tesio-Liv3 GNSS, etc, but there is no reason to not expect lifetime software updates
It's a completely false and outrageous claim that it will receive 'lifetime' updates but I see now that you're narrowing it down to simply receiving INCOMPLETE support/updates for the software indefinitely which applies to anything where you can install another OS and you're simply admitting to your explicit attempt to mislead people.
Not receiving firmware updates for every component, which is already the case today, means it's end-of-life. The Librem 5 is already end-of-life by the definition implemented by GrapheneOS. It cannot reach the current Android security patch level. There is no Android security patch that it could reach, since even the earliest ones required avoiding security weaknesses which are unavoidable on that hardware. It's a highly insecure device and no amount of your / Purism (likely one and the same) dishonest marketing is going to change that.
Linux kernel updates in no way guarantee security support for all the drivers, etc. which are being used, and there is no such guarantee for any of the device support code in userspace or any of the userspace projects. Security updates are not provided for many Debian packages. Only a subset of the security fixes get backported in the first place to those that are supported. Using Debian in no way implies getting indefinite or even current security support.
Any further contact with the GrapheneOS project or project members on your part or any further attempts to spread misinformation about it will be considered harassment as I already said earlier. We aren't interested in communication with you. If you don't stop contacting us, spreading libel about our project members and misinformation about our project, we'll begin contacting organizations/projects where you're involved about the harassment and malicious behavior across platforms towards an open source project.
Anyone can look at https://news.ycombinator.com/threads?id=amosbatto and see that you're heavily involved in marketing and providing customer support for Purism, which unfortunately involves spreading a lot of misinformation about both Purism's products, the company and about other open source projects which you aim to steer people away from and towards buying their products. We've already requested that Purism avoids contacting us and trying to harm our product. That extends to you too. You need to stop. This is your final warning.
As I already stated earlier, if you continued to spread misinformation, an article will be posted on our site with all the information that I posted here and more. That's going to be happening now. If you continue, then there will be a response directed towards you personally too, because you have made it person with the libel that you and other Purism employees/associates have regularly spread about us across platforms.
> It's highly likely that you have a financial stake in the company's products because nothing else would explain your devotion to so thoroughly misleading people and marketing their products across many platforms.
Let me state for the record that I have no financial stake in Purism, and I do not represent the company. I am simply a customer of the company who tries to correct the misinformation that I see being posted about the Librem 5 on public forums like this one, because I think that Purism is doing important development work for mobile Linux. I am using my real name "Amos Batto", and anyone who does a simple internet search can find my personal blog, my github page, my facebook page, etc. and verify who I am.
> If you don't stop contacting us, spreading libel about our project members and misinformation about our project, we'll begin contacting organizations/projects where you're involved about the harassment and malicious behavior across platforms towards an open source project.
This is ludicrous. You posted information which I consider to be incorrect about the Librem 5 on this forum and at r/Purism. When I responded to correct the record, you accused me of engaging in "harassment and malicious behavior across platforms towards an open source project".
Everyone can see your behavior and it fits a consistent pattern. You go out of your way to criticize other open source projects on public forums. Then, when people try to respond on the technical points, you accuse people of harassing you and trying to harm your project, which is simply not true. Responding to the technical points that you raised on a public forum is not an attempt to "contact" you or members of your project and it certainly is not "harassment" as you term it.
> I was simply following the standard convention of saying "Linux" to mean the entire OS that is found in popular distros like Debian, Arch and Fedora, whereas people generally say "Linux kernel" to refer to just the kernel. Saying "GNU/Linux" is problematic because most distros contain software which isn't part of GNU and isn't approved by the FSF, but I will use that term for lack of a better one.
So then Alpine Linux isn't Linux either? That's not a standard convention at all. It's a way of misleading people, and you're doubling down on it.
> By the way, it is just as problematic to say that GrapheneOS is "Linux" because GrapheneOS is using a kernel which has been substantially modified by Google, and Qualcomm's drivers for the Snapdragon which GrapheneOS uses are only designed to support an Android kernel, not a mainline Linux kernel. GrapheneOS doesn't use mainline Linux kernels and it usually takes 3-4 years for the mainline kernel to fully support new Snapdragons after they are released, so I don't know why you are even bothering to make this argument.
Why are you specifically talking about Snapdragon when the current generation and only recommended devices use the Exynos-based Tensor SoC? Current generation devices are using Generic Kernel Images and DO NOT have substantial modifications to the kernel. It's entirely possible to use the kernel.org LTS releases.
GKIs have a stable ABI for kernel modules, and all of the kernel modules for all the generations of devices were already open source despite inaccurate claims to the contrary here.
> Just to be clear, I'm simply a customer of Purism and PINE64 who owns the Librem 5 USA and PinePhone, so I don't represent these companies and I'm not marketing their products.
You're marketing their products and are heavily involved in spreading misinformation about AOSP and GrapheneOS. We consider you to be malicious and you're now involved in spreading libel about our developers. There will be a response to that if you continue down that path. It's likely that you're financially tied to them.
Please stop contacting our project members and refrain from involvement in our community going forward. It will be considered harassment and will be responded to as such.
> I'm not sure whether there is a larger ecosystem of open source apps for Android rather than the GNU/Linux distros that run on the Librem 5 and PinePhone. If we are talking about apps which are designed to run on mobile phones, then you have a point, since it will take a while to adapt all the desktop software to be mobile-friendly, but Kirigami or libhandy/libadwaita is getting added to a lot GNU/Linux desktop software to make it adaptive. Google purposely does not label software with FOSS licenses in the Play Store, so it is hard to count the number of FOSS apps for Android. I count 4472 apps in F-Droid (https://f-droid.org/repo/index-v1.jar), whereas Debian 11 "bullseye" (which is what PureOS and Mobian are based on) has 59,551 packages. I know that not all FOSS apps make it into the F-Droid repo and the Debian repo includges the entire operating system and many of its applications use multiple packages, so we are comparing apples and oranges, but I don't see much evidence that the Android FOSS ecosystem is "larger and better" than the GNU/Linux ecosystem.
This is another demonstration of how unserious you are about remotely sticking to the truth where you venture off into claims that aren't even remotely plausible. F-Droid is a tiny subset of the overall open source Android app ecosystem. Again, it doesn't even have Signal, Firefox, any Chromium-based browser or MANY other widely used open source apps, let alone non-widely-used ones. I have no clue why you're referring to the total number of packages in Debian as anything to do with the number of mobile applications. It's another completely, thoroughly dishonest misrepresentation of the truth.
> I stated that "the Librem 5 doesn't need an IOMMU" to isolate the WiFi/BT, cellular modem, GNSS and USB controller, but in case you are worried, the i.MX 8M Quad SoC in the Librem 5 does have a Resource Domain Controller (RDC), Arm TrustZone and On-chip RAM (OCRAM) secure region protection, which does isolate the CPU, GPU and VPU. See section "3.2.2.4 Resource Domain Control and Security Considerations" in the "i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual". (NXP requires registration to download the manual.)
It does not isolate either the on-SoC or off-SoC components in a remotely comparable way to Snapdragon, Exynos or Tensor. It's also not configured for production use and security properties which could have been provided are far from all being provided.
> The GrapheneOS FAQ lists the Pixel 3a released in May 2019 as a "supported" device, but the Pixel 3 released in October 2018 is listed as "end-of-life" because it no longer gets full security updates, so that tells me that most people are using GrapheneOS on devices that have a 3 year lifespan.
The current generation devices have a minimum of 5 years of support, as has already been stated. The Pixel 3 still receives GrapheneOS updates. It's considered a legacy device as the Librem 5 would have to be considered a legacy device already due to inability to reach the current Android security patch level for many reasons. This was already stated multiple times, and you're once again doubling down on inaccurate claims.
> I downloaded the Pixel 3a's "bonito" kernel (https://github.com/GrapheneOS/device_google_bonito-kernel) and I see that it is using kernel version 4.9.292. Mainline Linux 4.9.292 was released on 2021-12-08 and 4.9.0 was released on 2016-12-11. Call me crazy but I prefer to use an up-to-date mainline kernel rather than one that is over 5 years old and takes 3 months to get the latest security patches from kernel.org. (To be fair, I should mention that the Librem 5 issn't yet fully supported in mainline Linux, so you can't run the latest mainline kernel on day one of its release, but the Purism devs say that mainline support is coming.)
The Pixel 3a / Pixel 3a XL are on the March 2022 Android security update including for the kernel and have additional patches backported to them. Their kernel is based on the Android Common Kernel, which is only indirectly based on the kernel.org releases. Ubuntu doesn't use the kernel.org releases in general at all and that does not mean their kernels are less secure, just because they do not update to newer kernel.org releases because there are none for their kernel branch, which they maintain themselves. This is how Linux works across distributions. Can you name one distribution directly shipping kernel.org releases without patches? Even Arch Linux doesn't do that.
A subset of the kernel.org changes is shipped by AOSP on a monthly basis with additional backports by GrapheneOS. The kernel.org releases are shipped by AOSP as part of the quarterly updates, they get shipped approximately every 3 months. GrapheneOS is fully capable of shipping the latest kernel.org releases but we found that there are too many regressions including security regressions and we stopped shipping them faster than AOSP for most devices. The current generation devices, which for some reason you feel like ignoring in favor of 3 year old ones use Generic Kernel Images and can be trivially updated to the latest kernel.org LTS without any changes since there are ZERO device-specific changes to the kernel. Maybe you should stop trying to make dishonest and misleading comparisons by comparing the latest generation of one device to 3 generations ago for another device, while adding in your own inaccurate claims to that.
For your information, the Pixel 3a has not been vulnerable to many of the most recent serious recent kernel vulnerabilities unlike the Pixel 6 because it's on the 4.9 branch instead of the 5.10 branch. The 5.10 branch has massively more complexity, attack surface and does not offer substantially improved security. The new mitigations in the Android 5.10 common kernel.
@anw, According to the Purism forum, the shipping queue for the Librem 5 has reached people who pre-ordered on October 20-25, 2017, so you should have gotten your phone by now. You should contact Purism support to ask about your order. See: https://forums.puri.sm/t/estimate-your-librem-5-shipping/112...
It depends on your goals. If you donate to the GNOME Foundation, your donation won't help develop Phosh (which is the leading mobile Linux interface according to 3 different PinePhone user surveys) and it probably won't be used to make GTK/GNOME ecosystem become adaptive and mobile-friendly. If your goal is to advance mobile Linux on the GTK/GNOME/Phosh platform, then ordering the Librem 5 is the best way to get funds to the 10 software devs working on it at Purism. See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
I own both the PinePhone and Librem 5 USA, and I'm seriously impressed by the amount of work the Purism devs do for PinePhone users (who are the majority of the Phosh users).
As for Xiaomi being comically large, I found the mid-range Samsung and Motorola models to have larger bezels and to generally be larger for similar specs when I bought my Xiaomi Redmi Note 7 a couple years ago. The reality is that the majority of phones from Motorola, Xiaomi, LG and Nokia are designed and manufactured by 3 Chinese ODMs (Wingtech, Huaquin and Longcheer), and even 20% of Samsung's phones come from these 3 ODMs. See: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...
Hi, I'm the "random community member" who wrote that FAQ answer. Thanks for investigating how this works. Where is the file cpu_rec.py located? I can't find it.
I will edit the FAQ answer to clarify that the DDR training blobs are being executed on an ARC core in the DDR controller, and not on the M4 core. I was going off what Angus Ainslie wrote (https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...) that 'the M4 is the “secondary processor” that handles the blobs', and I conflated "handles" with "executes".
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, and Ainslie's article on the Purism web site and Nicole Faerber's talk (https://media.ccc.de/v/Camp2019-10238-a_mobile_phone_that_re...) both explained how Purism is using the secondary processor exception in the RYF rules.
It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5. Raptor Computing is now facing the exact same problem with the proprietary Synopsys DDR4 timing blobs in the POWER 10 processor, so this is actually a common problem with most modern processors. 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.
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 and make the Librem 5 no different than an Apple device with an M1 processor, which is literally a black box. Forget the fact that the L5 is the first phone to have free/open source schematics since the GTA04 in 2012 and we know the 1267 components on its PCBs, plus we have 7000 pages of documentation for the i.MX 8M Quad processor, and everything is running free/open source drivers.
There is only so much code that you can hide inside 58 KB of blobs and that early in the boot sequence, you can't rely on anything else being operational in the device, so you would need to have all the code to initialize and control components on the phone. 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. It isn't hard to verify that the blobs that are stored inside the L5's SPI NOR Flash chip are the same ones being distributed by NXP, so then you are left with the theory that NXP or Synopsys are distributing blobs that do something malicious, which would be suicidal for either of those companies if anyone ever discovered it. Supermicro's stock lost 40% of its value after Bloomberg published one story about the Chinese government inserting spy chips in Supermicro motherboards, and nothing in Bloomberg's article was verifiable. Companies like NXP and Synopsys are very unlikely to risk their businesses, even if the NSA asks them, so I find the whole scenario far-fetched.
> 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:
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.
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.
> 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.
> 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.
Before anything else, let me say thank you for your work on the M1, because it is essential that we have Linux support for processors even when the device maker is opposed. Considering how many millions of people have bought Apple's M1 devices, Asahi's work is critical because it provides a path for people to discover a freer system when they get disgusted with Apple's bad practices and the restrictions of its "walled garden."
You are comparing the work of a company with two kernel developers (Angus Ainslie and Martin Kepplinger) to an entire community working on Linux support for the M1. Purism has only shipped 2600 Librem 5's so far, whereas Apple is shipping roughly 7 million M1 Mac PCs and 15 million M1 iPads every quarter. If you are going to brag about getting M1 support into mainline Linux within 4 months of the release of the M1, consider the fact that the first commits to mainline Linux for the i.MX 8M processors were submitted just 8 days after NXP announced that it had started volume shipping of the processors (https://www.pengutronix.de/en/blog/2018-01-17-first-mx8m-mai...). This was possible because NXP shipped early versions of the processor to many companies and has released 7000 pages of documentation on the processor, plus NXP pays several of its own employees to work on getting the i.MX 8M supported in mainline Linux. It does make a huge difference whether a company decides to collaborate with the Linux community or not.
You also have to keep in mind that Apple has shipped 2 billion devices with A-series processors that never got mainline Linux support, so we got really lucky that 1) Corellium managed to figure out how to run Linux on the M1 and 2) Apple decided to not block the use of custom kernels with the M1. Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017 (https://craft.co/corellium) and company's blog makes clear that it was its previous work on the A-series (boot sequence, PCIe and USB controller) which helped it get Linux support working so fast on the M1 (https://www.corellium.com/blog/linux-m1), so Corellium wasn't starting from scratch in figuring out how the M.1 works.
By the way, it's worth pointing out that most of Purism's dev work hasn't focused on the kernel, but has instead focused on creating the Phosh mobile environment on top of GTK/GNOME, and Purism has created about a quarter million lines of new code so far (https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr...), and 169.4k of that code (libhandy, libadwaita, Chats and Calls) has been incorporated as official GNOME projects. Purism purposely designed the L5's software to work as a thin overlay on top of an existing desktop Linux stack, so PureOS/Phosh has done a better job than Meego, Sailfish OS, Firefox OS, Ubuntu Touch and WebOS at making a version of mobile Linux which is compatible with the larger Linux ecosystem. Purism commits upstream as much as possible to projects like Linux, wlroots, ModemManager, Geoclue, GTK, GNOME and about 20 different GTK/GNOME apps (Nautilus, gEdit, GNOME Calendar, CNOME Contacts, GNOME Clock, etc.) so that the L5 will be easier to maintain and be able to run on other Linux distros (postmarketOS, Mobian, Ubuntu Touch, etc.).
> To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might)
The i.MX 8M does have a secure boot option, but Purism isn't going to use it because it isn't controllable by the user. Purism's Kyle Rankin commented that they are discussing how to implement a user-verifiable boot procedure, like they have with PureBoot + Librem Key on their laptops, but Purism has a lot of other stuff on its plate (like suspend to RAM, camera auto-focus, encryption with keys from the OpenPGP card, etc.) which is higher priority, so I doubt that it will be implemented soon. The Ubuntu Touch port should have secure boot, but UBports has put their porting of the L5 on hold to focus on the PinePhone and PineTab, so I assume that will also take a while.
>Apple decided to not block the use of custom kernels with the M1.
More like deliberately modified their design to allow it.
>Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017
I don't think Corellium did have much effect on the Asahi upstreaming effort, they just posted haphazardly patched up kernel tree which they were using for validation of their virtualization platform. Majority of their patches weren't suitable for upstream submission.
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-...
(read her comments in the libreboot policy she linked to)
> 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-certific...
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...
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...), 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.
>As I see it, we got lucky with the x86 architecture
x86 situation is actually horrible. Not only there are SMM interrupts that are continuing to execute firmware code outside of OS control, it also has proprietary security processors running signed code (ME/PSP) with potentially unlimited access to main memory. M1 fares much better in category of "amount of proprietary code running that might affect your security": no firmware code running at all on the main CPU after bootloader passes control to the OS, and all coprocessors are safely gated behind IOMMUs.
As for other ARM PC consumer devices, they will probably use whatever Windows requires to boot, which is UEFI + ACPI.
It would be almost impossible to make a phone with parts that are entire manufactured in the US. Most silicon foundry work is done in Taiwan (TSMC, UMC, Vanguard) and S. Korea (Samsung, DB HiTek). See: https://www.cnbc.com/2021/03/16/2-charts-show-how-much-the-w...
Yes, the CPU is weak, suspend-to-RAM hasn't yet been added to the mainline Linux driver for the i.MX 8M, camera auto-focus doesn't yet work, and lot of work is needed for full functionality of the Megapixels camera app and use of an OpenPGP smartcard, but you are ignoring all the progress that has been made. Purism started with a new chip that didn't yet have good mainline Linux support and had to make several hundred commits to mainline Linux to support half a dozen new chips. Purism created a new mobile environment for Linux, which 65% of PinePhone users say in a poll is their favorite interface. Purism created the first free/open hardware phone since the Golden Delicious GTA04 in 2014 and manufactured the first phone in the US since the Motorola Moto X in 2013. The Librem 5 contains 6 innovations in the mobile phone industry, which is more innovations than any phone since the Samsung Galaxy S5 released in 2014. This is the first phone ever produced where the manufacturer promises lifetime software updates and the processor will be produced by the manufacturer (NXP) until at least Jan. 2033.
The NXP i.MX 8M Quad processor in the Librem 5 has "Made in Korea" stamped on them and there have been news articles published about how NXP was switching its foundry work from TSMC to Samsung. By the way, the i.MX 8M is designed in Austin, Texas (by the old Motorola division, which turned into Freescale and then was bought by NXP).
Purism has said that it will be providing proprietary firmware updates, and it already has instructions how to update the firmware for the RS9116 WiFi/BT on its web site.
Because Purism selected components for the Librem 5 that will be manufactured for many years, it is more likely to get firmware updates than most smartphones. Because the drivers are all FOSS, they can be updated by the community, and some cases the manufacturer helps maintain the mainline Linux drivers, so timely updates are very likely. For example, NXP promises to sell its i.MX 8M Quad processor until at least Jan. 2028 and it helps maintain the mainline Linux driver. Likewise, Redpine Signals helps maintain the mainline driver for the RS9116 WiFi/BT and likely to keep manufacturing the chip for at least the next 5 years.
In contrast, the SoC used in a typical smartphone is only manufactured for 1-2 years and it typically only gets 2-3 years of support from the manufacturer, so the Librem 5 is more likely proprietary firmware updates than most smartphones.
As for the question of whether it is better to store the proprietary firmware in the /lib/firmware directory or in the component or in Flash chips on the motherboard, there are advantages and disadvantages, so you have to weight what is important. When firmware is stored and loaded from the /lib/firmware directory, it is easier to update and the user will automatically get the latest firmware when upgrading the software on the device. In contrast, the user has do a separate procedure to upgrade the firmware and many users are unlikely to do it, so any potential security holes in the firmware are less likely to be closed with updates. However, a lot of this depends on what Purism does in the future to push firmware updates, so we shouldn't automatically assume that the Librem 5 will be insecure. The benefit of not storing the firmware in /lib/firmware is because it makes the user more conscious of the proprietary blobs on the device, and the user can make a deliberate choice whether to install firmware updates or not, after reading the description of each update. Also, it is harder for the firmware to be hacked by a bad actor when it is stored in the component or a separate Flash chip, because it requires a separate procedure to flash the firmware, so it can be argued that it is more secure. Another benefit is that system updates can be offered without including any proprietary files, so there are no restrictions on how they are distributed and installed.
In terms of promoting software freedom, I don't know of any cellular modems or any GNSS with FOSS firmware. There were only two WiFi/BT model series whose firmware was reverse engineered by the community but they never got past the experimental state and are now hopelessly outdated since they were 802.11b/g devices. There are some ath9k 802.11n models that required no firmware, but they have poor range and are energy inefficient and require proprietary firmware for the Bluetooth.
In other words, there is no realistic way to make a modern computing device without proprietary firmware, and the only hope is to pressure the manufacturers to release code or documentation for its firmware, but the modern patent situation with wireless communications makes that extremely unlikely to happen. However, the FSF's insistence on trying to separate the proprietary firmware and not let it be executed on the main CPU cores does draw public attention to the problem and show the component manufacturers that there is public demand for free firmware. When companies like Purism go through extreme steps to avoid executing DDR timing code on the main CPU cores, by adding a separate SPI Flash chip to the board to hold the blob and not using the Cortex-M4 core for any other purpose but to execute that blob, it sends a message to NXP that its customers really hate that proprietary blob and it should be eliminated. In contrast, a company that stick that blob in the main Linux file system tells NXP that its customers don't care about that blob and there is no pressure for NXP to eliminate it in future chips. The value of buying RYF products like the Librem 5, RaptorCS computers and Lulzbot is that it is creating a public statement that consumers care about not having proprietary blobs, and that the hardware industry should cater to that crowd. What Purism is doing value in promoting a public message and it is based on a long-term strategy to pressure the industry to free its firmware, whereas the people who criticize it have no strategy for ever achieving change. If they have an alternative strategy for how to free the firmware, I would love to hear it.
The more important point is that Purism selected components from hardware companies that are more willing to collaborate with the community and listen to Purism's requests, so there is more possibility of driving change up the supply chain. Purism paid Redpine Signals to modify its firmware so it could meet the RYF criteria and NXP engineers work with the community on the mainline Linux driver for the i.MX 8M, so it is possible to influence these component suppliers.
It is likely that someone who owns a botnet saw Rossmann's criticism of Purism and decided to that the company deserved to be attacked, which is a really rotten thing to do, because then people assume that Purism is hiding something.
I agree that Purism should have refunded the cancelled orders, but calling the company a "scam" is way over the top, considering the huge amount of dev work that Purism has done on mobile Linux and the Phosh interface. I own both the Librem 5 and Librem 5 USA and the company is definitely not a "scam".