Hacker News Search

marcan_42 5y ago

strcat is right here. Purism designs and markets their devices, effectively, to cater to a crowd that believes that devices with actual security are inherently evil, because they do not understand it. You can have better security with user control, but for that you need to look at the details. They don't care about the details; their story is all fluff under the guise of freedom and privacy. Purism's marketing material is outright deceptive, e.g. they insist that in competing phones the baseband blob has access to system memory, which is a lie. The reality is that the baseband blob in the Librem 5 (which is every bit a giant blob as that in the competition) has access to the USB port of the AP and there is no filtering implemented yet, so the attack surface it is exposed to is every USB driver in the Linux kernel, which is much worse than systems with embedded basebands and proper memory firewalling where the baseband has no more inherent access, but is exposed to a smaller attack surface. That means that you are more vulnerable to giant blobs doing evil things with a Librem 5 than with, say, an Android phone running a free OS build. Then there's the whole hilarious situation with the RAM initialization blob where Purism went and hid it behind two layers of CPUs (not execution, just handling it), because somehow doing that - which provides absolutely no benefit to the user, it's just a waste of engineering time - made it possible to certify the phone under the FSF's utterly broken and nonsensical "Respects your Freedom" program, even though precisely zero freedom was gained by doing this, since it still running the same blob on the same final CPU with the same access. All the while while reducing security, since the blob is then made no longer part of the normal OS image and is not validated with it, so it could be backdoored as part of a supply chain attack and you would be none the wiser. The whole thing just stinks the more you look into it, and it is completely evident that the folks behind Purism are a mix of deliberately deceiving people and just clueless about security and modern embedded platforms.

strcat 5y ago
It's immensely frustrating for us (GrapheneOS) because we desperately want more devices to support but the devices supposedly focused on privacy/security are really massive setbacks for it. We want to convince vendors with the resources available to produce devices on the same security level as Pixels with a couple additional features. It would also be neat to be considered an official OS without the verified boot notice from loading a key from the secure element instead of a hard-wired key in the firmware, but that's not important. We've found one vendor interested in listening us and acting on it. It remains to be seen how that goes. Our perspective is that this has been made immensely harder by the dozens of 'secure' phone companies providing something far worse than iPhones and Pixels. Most of those aren't presented as being 'open hardware' that's not at all open hardware, but they do share a lot in common. A few of them were so bad that they were actually law enforcement stings from the beginning (https://en.wikipedia.org/wiki/ANOM https://en.wikipedia.org/wiki/ANOM) or turned into them (https://en.wikipedia.org/wiki/EncroChat https://en.wikipedia.org/wiki/EncroChat) which is amusing. We'd happily target iPhones but Pixels are the only smartphones providing proper alternate OS support. On Pixels we get to have full verified boot covering all the OS images with downgrade protection, very nicely designed hardware attestation, all the hardware keystore capabilities, the disk encryption key derivation throttling feature with insider attack resistance, A/B updates for the firmware/OS, etc. This is the stuff we expect other vendors to provide us with in order to support their phones. Vendors using a flagship Qualcomm SoC, including the alternate OS verified boot / attestation support and doing a good job with security work themselves come close, but we need more than that. There's a fair bit missing without vendors caring enough to go above and beyond with security and alternate OS support. When we look at the Librem 5, what we see is rolling back privacy/security massively on the hardware, firmware and software levels with no possible way we could support it. We were actually in contact with them at one point but it became clear that they had zero interest in anything more than an empty partnership where out name would be used for marketing without us being able to use the device at all. That was back before lots of the security improvements in the Android smartphone world where Pixels caught up and even surpassed iPhone security in most areas. Our expectations used to be far lower, and they get higher as devices like iPhones/Pixels get better. For example, Weaver showed up with the Pixel 2, as did the related secure element insider attack resistance where the main owner user has to authenticate for firmware updates to be applied. Before then, the SEP was way ahead in this area, and continued to be ahead in a lot of others until the Titan M. Weaver provides always enabled aggressive throttling for disk encryption key derivation attempts, with full support for the separate per-user encryption keys. It quickly throttles up to 1 day per attempt after 140 failed attempts. We take it for granted that we get all this stuff including the hardware keystore with physical confirmation support, etc. We expect these features from other vendors. It's not a lot to ask that they implement a feature like Weaver which was introduced with the Pixel 2 via open source AOSP code for the OS integration and open source secure element applets for an off-the-shelf Java smartcard secure element. That got obsoleted by the Titan M, which is actually well on the way to becoming open source with OpenTitan and the Pixel 6 shipping a RISC-V implementation of it based on that. It would be great for that to be fully open sourced and usable by other vendors. That's the kind of thing which is exciting in this area. Pixel 6 using Trusty OS for TrustZone isn't that compelling since TrustZone is terrible and largely obsolete beyond being the component responsible for talking to the actual secure element via authenticated encryption. They're also on the path to getting rid of it now that there's proper virtualization support, which is where the nonsense like Widevine is moving to be properly unprivileged/isolated unlike the mess of TrustZone. It would be great if other vendors actually cared more and tried to actually compete with iPhone and Pixel security. We found a vendor that's willing to put in the effort, and we're optimistic about that. We're more than happy to work with others. The main thing we need to do is point them at what they need to implemented and the existing open source AOSP code for the OS side of it, etc. We have a lot of experience with this including reporting a bunch of firmware vulnerabilities / bugs in Pixels. There are so many things which could be done better but it starts with any other vendor catching up to where iPhones / Pixels where years ago.
- fsflover 5y ago
  Why can't you port Graphene OS to Librem 5 and use its security features there? Librem 5 is actually based on FLOSS drivers unlike any Android phone, so it should be doable. It's also the only phone with a FLOSS OpenPGP card .
  - strcat 5y ago
    Please read https://news.ycombinator.com/item?id=30761693 https://news.ycombinator.com/item?id=30761693 and the other comments again. Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required. It's also missing functionality beyond that required to run the full OS. > It's also the only phone with a FLOSS OpenPGP card . It has no such thing (there is no open source secure element available aside from OpenTitan, although Trezor is working on one too) and it isn't an alternative to a proper secure element used by apps via the standard AOSP hardware keystore API (StrongBox keystore) and integrated into the rest of the hardware/firmware/OS for verified boot, attestation, throttling disk encryption key derivation attempts, insider attack resistance (only allowing signed firmware updates after owner account authentication) and the other features that are provided.
    - marcan_42 5y ago
      And what little "security" features the Librem 5 has, they aren't even using. One of their engineers came at me with "we have RPMB!" (a poor excuse for anti-replay memory that is semi-standard these days, and vastly inferior to dedicated chips like Pixels and iPhones have). I asked what they use it for, and got crickets.
rhn_mk1 5y ago
> the attack surface it is exposed to is every USB driver in the Linux kernel, which is much worse than systems with embedded basebands and proper memory firewalling where the baseband has no more inherent access, but is exposed to a smaller attack surface. You're saying that as if the firewall handled the communication with the modem. There's a Linux driver behind the firewall to do the actual communication, except that's probably not a USB driver. The attack area is probably comparable, except a misconfigured USB driver doesn't automatically give full memory access, while a misconfigured IOMMU (the firewall) does.
- marcan_42 5y ago
  There's a linux driver behind typical basebands. One driver, since there is no device discovery for platform devices. The Librem 5 doesn't have one driver exposed to the baseband. It has every single USB driver in the kernel exposed to it, because the baseband can present any descriptors it feels like and engage whatever driver it wants, or a combination thereof by presenting itself as a composite USB device, since USB is plug&play. That is a massively larger attack surface. All you have to do is find one exploitable bug in any USB driver in Linux, and you're in. This can be mitigated with USB descriptor filtering, but the Librem 5 guys haven't implemented that yet, because they don't actually care about security. So while their marketing department is lying about DMA access for the competition (heck, as far as I know no iPhone gas ever given the baseband unchecked DMA access to the system, but Purism claims they all do!), their engineering department can't even bother to lock down the attack surface of the baseband to something smaller than "every single USB driver in the kernel". Also, for what it's worth, the Librem 5 doesn't even have an IOMMU at all. They can't even use the PCIe ports in their SoC because that would give whatever you plug into them full DMA to the system. This also means that driver bugs that result in bad DMA descriptors for embedded SoC devices will directly escalate to full memory access; there is no safeguard by having to engage the IOMMU subsystem first to map them.

jancsika 5y ago

> Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options doesn't make it secure or more secure than those. That's true and relevant to Purism. Now, how about something true and relevant to your post wrt FOSS: > GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. Tell me about the license for the source of "all the firmware." And keep in mind you found it important enough to reiterate the point about "no closed source" for the kernel drivers.

strcat 5y ago
> Tell me about the license for the source of "all the firmware." And keep in mind you found it important enough to reiterate the point about "no closed source" for the kernel drivers. There isn't anything remotely misleading about the correction that kernel drivers are not in the same situation as most firmware in that they're entirely open source. Every ARM SoC is a proprietary SoC with proprietary CPU cores, memory controller, GPU, image processor, radios and all the other massive complexity included in them. There's a ton of firmware involved in that proprietary hardware. It exists whether or not it's updated. Not updating the radio, GPU, etc. firmware doesn't mean it doesn't exist. Whether or not it's open or closed source has little relevance to the need for it to be hardened, properly isolated and updated. Open or closed source does not directly provide any privacy or security properties. Other components outside the SoC are almost always closed source too. We don't think the fact that the Pixel 6 has a TEE OS based on the open source Trusty TEE or a RISC-V secure element based on OpenTitan makes it inherently more secure than Qualcomm's offerings. Pixel 6 having a Samsung cellular radio and Broadcom Wi-Fi/Bluetooth radio as 2 separate chips from the SoC instead of being part of the SoC has not made those more isolated or more open, and if anything we consider moving away from the Qualcomm radios to be a security regression with how well Qualcomm hardens them, although the overall improvements make up for it. If we made a device, it would have a Qualcomm Snapdragon 8 Gen 1, and we'd be quite happy with having the most secure radios, hardware memory tagging support and Qualcomm's great security work elsewhere. Would it be nice if we could have more control and insight? Sure. If a theoretical currently non-existent open source RISC-V smartphone SoC existed and it had comparable privacy/security (which would be very difficult), we'd be very interested. It would take massive work beyond simply having a viable SoC in the performance class with the necessary functionality to make anything remotely competitive on a security level. GrapheneOS is a non-profit open source project and doesn't produce or sell hardware products. We don't do consulting, exclusive deals with companies or anything like that. There is no intention to ever sell any products, but rather we research hardware, report issues upstream and choose the best available hardware as the officially supported targets. We also intend to work with hardware partners on equal footing with nothing exclusive to help them produce better devices, which will benefit them and will benefit us through having more and better devices to support. We could potentially get more reliable donation revenue through devices with GrapheneOS installed, but that's in no way any kind of requirement for us to work with vendors. We have little to no interest in ever selling devices ourselves. We're fine with the fact that over a dozen companies sell devices with GrapheneOS installed mostly without giving anything back to us. Only a couple give us any form of donations/support. This is not a business. The claim that there are closed source kernel drivers is untrue for most mainstream Android devices and is a misunderstanding of why devices stick to a specific LTS kernel branch. Those branches receive 6 years of support now because of the model that's used for mainstream embedded / mobile devices. They don't want to port their drivers to newer versions and spend a year getting it working robustly again. It would be entirely possible to do it and it's possible it will happen for Tensor but it can be an overall bad thing for security instead of a good one due to all the added attack surface. A great example is how a bunch of recent vulnerabilities such as 'Dirty Pipe' only impacted the Pixel 6 due to it using the 5.10 LTS branch which was the newest at the time. A Qualcomm device wouldn't have been impacted due to having an older kernel branch.

blihp 5y ago

> GrapheneOS and AOSP are Linux-based and there are no closed source kernel modules. I ran AOSP builds for years and that's a half-truth at best. Sure for the kernel proper, you have the source. However, there are a fair number of closed source drivers for the GPU, modem, wifi etc. From the GrapheneOS Wikipedia page[1] it sure looks like they're following this model. If I am mistaken and there is a miraculous state-of-the-art SoC with completely open source drivers being used by a major handset maker, do tell. You'll be a hero in the open source world for pointing out something everyone else has overlooked. > Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source. It has everything to do with things being closed source. Try doing a Linux kernel major version upgrade with binary-only drivers for key components sometime. It sounds like the only reason GrapheneOS works is because they're 'drafting' off of the kernel and driver work done by Google, not that they've cracked that particular nut themselves. Nothing wrong with that, but it does limit the useful life of a device to the first major security issue they can't fix due to a lack of source code. Regarding the rest of your response, you're assuming that I was speaking to the Librem 5 specifically, I was not. Notice that I was only speaking about the goal of a 'pure' Linux phone since that was what seemed to be being asked about. Personally, I have a PinePhone[2] and wasn't interested in rehashing the various issues with the Librem 5. [1] https://en.wikipedia.org/wiki/GrapheneOS https://en.wikipedia.org/wiki/GrapheneOS [2] which itself is far from perfect, but comes a lot closer to being a 'pure' Linux phone.

fsflover 5y ago
> If I am mistaken and there is a miraculous state-of-the-art SoC with completely open source drivers being used Not a major handset maker and not Android, but https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor. Also, not state-of-the-art, too.
strcat 5y ago
> It has everything to do with things being closed source. Try doing a Linux kernel major version upgrade with binary-only drivers for key components sometime. It sounds like the only reason GrapheneOS works is because they're 'drafting' off of the kernel and driver work done by Google, not that they've cracked that particular nut themselves. Nothing wrong with that, but it does limit the useful life of a device to the first major security issue they can't fix due to a lack of source code. As stated earlier, there are no closed source kernel drivers for AOSP, GrapheneOS or even most mainstream Android devices running the stock OS. The reason for using an LTS kernel branch with 6 years of support from kernel.org is stability. Porting forward the drivers to each new kernel release is entirely possible and isn't a lot of work when it's done incrementally. Not that many changes are even required. The issue is that there are substantial regressions in each Linux kernel release and it takes at least 4 months or more to get a production quality kernel for a specific hardware target with nothing break, the massive CTS/ITS/VTS passing, etc. Pixel 6 uses the Linux 5.10 kernel branch which was the latest at the time, and those LTS branches have 6 years of support from kernel.org and expanded support with more bug fixes / security enhancements / other improvements via the AOSP common/generic kernel. It's entirely possible to move to a newer LTS branch. There are no closed source kernel drivers. Is it worth the time, when newer LTS branches have substantially more attack surface and tons of regressions that are going to need to be detected/fixed? Bear in mind it would not expand the lifetime of devices at the moment, time several hardware components won't receive more than 6 years of firmware support. There are already people who have gotten the mainline 5.15 kernel working with the Pixel 6, but from 5.10 to 5.15 there are a lot of regressions, and there's a lot of new attack surface. There's a reason that ONLY the Pixel 6 among the Pixel family has been vulnerable to several serious core Linux kernel vulnerabilities disclosed in the past few months including the branded dirty pipe vulnerability. There are both advantages and disadvantages to using a newer LTS branch. Unfortunately, one of the disadvantages is that there are more bugs overall, including more vulnerabilities overall. Many software projects mature over time and the rate of finding vulnerabilities goes down. That's not the case for the Linux kernel. It's having vulnerabilities introduced at a faster pace than they're fixed. It isn't better from a security perspective to use the 5.15 LTS rather than the 5.10 LTS, especially with the additional changes backported by AOSP including security enhancements like mitigations, not just bug fixes. It may be a good idea to move to the new LTS branch once it has matured for 1-2 years, but definitely not months after release.

amosbatto 5y ago

> 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/ 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/Frequently-Asked-Questions#39-will-the-librem-5-get-proprietary-firmware-updates 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/Frequently-Asked-Questions#311-how-can-purism-provide-lifetime-software-updates-for-the-librem-5 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/Frequently-Asked-Questions#43-how-secure-is-the-librem-5-compared-to-an-android-phone 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"?

The general idea behind any 'pure' Linux phone is to have a device that you can trust at least as much as a desktop running Linux. Security is definitely a key

The general idea behind any 'pure' Linux phone is to have a device that you can trust at least as much as a desktop running Linux. Security is definitely a key