3 ms·

Those devices have atrocious security at a hardware, firmware and software level. Their microphone kill switch also doesn't prevent audio recording. They aren't

by strcat 7mo ago

Those devices have atrocious security at a hardware, firmware and software level. Their microphone kill switch also doesn't prevent audio recording. They aren't open hardware despite many attempts to mislead people with the marketing. > The latter even has most of the modem software freed. Pinephones have entirely closed source baseband firmware. They use a highly unusual cellular radio which includes both an incredibly outdated Qualcomm baseband processor with atrocious updates and security combined with an extremely outdated proprietary fork of Android running on an extra CPU core which isn't present in any mainstream smartphone. It's only replacing the unusual extra OS which has been done. That whole component doesn't exist on other smartphones and the only reason it's possible to replace it is because the whole radio has absolutely atrocious security. The radio is connected via a far higher attack surface USB connection providing far less isolation for the OS and the USB connection can be used to flash the proprietary Android OS via the fastboot protocol. The baseband firmware itself doesn't have any replacement available.

daneel_w 7mo ago
> Pinephones have entirely closed source baseband firmware. > The baseband firmware itself doesn't have any replacement available. Same with the Google Pixels and their Samsung Exynos modem. Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers. What will it be for the upcoming Motorola phone?
- ysnp 7mo ago
  Hi daneel, what would you like GrapheneOS to do while you develop your own formally verified, open hardware, open source firmware/OS baseband processor they can use? Sit on their hands doing nothing or making the best of the least worst options currently available?
  - daneel_w 7mo ago
    The Pixels already are the best of the least worst options currently available. Anything new must categorically bring improvements, and the closed source firmware of the Pixels is a pressing point.
    - handedness 7mo ago
      That's reasonable, and I hope we get there. Qualcomm is an American company, and it sounds like the GrapheneOS team is working directly with them on developing the spec for this, including hardware MTE support. That's promising and I think could bring improvements over the current situation, if not open source modem firmware, unfortunately. I'm hoping to be surprised, though.
- DANmode 7mo ago
  > Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers Pixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of it?
  - daneel_w 7mo ago
    Neither. It's great that the Pixels' baseband ACPU doesn't have free reign in system memory, but if we're gonna underline the deficient state of the cellular modem in the Pine Phone we should also remind ourselves that the firmware situation with the Pixels is an almost equally sore thumb.
    - DANmode 7mo ago
      It doesn’t feel equal to me, here in my real-world usecase.
    - handedness 7mo ago
      There's a lot of hand-wringing in this thread about Motorola's location, and a lot of support from a few for a modem made by a company headquartered in....Shanghai. If consistency here is what we claim to be pursuing, then let's actually pursue it. The opacity of the firmware situation isn't great on either, but one contains numerous excellent mitigations and is very proactively maintained, and the other is something that relies heavily on reverse engineering and community projects to even use. And it has a physical switch and has some physical distance between it and the CPU, both of which given the previous limitations are mostly theater, in practice. "My modem is so vulnerable it needs to be turned off during extra-important times, but I don't mind leaving it on during times that are merely important." As if a compromised OS can't just wait to exfil data. If your goal is to make it to Checkpoint Charlie and don't want the hassle of having to buy a new phone after you reach freedom, fine, but I haven't seen many well-articulated needs that would be satisfied by a hardware switch when everything behind that switch is filled with vulnerabilities. For my threat model, using the modern modem with a bounds sanitizer, an integer overflow sanitizer, stack canaries, control flow integrity, automatic initialization of stack variables, very active updates and a large commercial user base and a large market cap in part depending on it, makes a lot more sense. Google's highly lucrative ad tech business is what makes everyone nervous about anything Google, rightly so, but their share price would plummet if they were caught using Pixel hardware in nefarious ways, or did an unreasonably insufficient job in securing it. I'm not saying it's not possible that the modem is compromised, but for my threat model I have to put a lot into the possibility of an undetected backdoor inside a modem which is by all indications constructed very well, to make using a weird old modem known to be massively lacking in dozens of ways, running an OS with all kinds of issues, make more sense. And I say that as someone who tried the PinePhone at one point. Fun idea, but no commercial or state organization with an elevated risk profile would trust their data to a PinePhone as it stands. It's fun for hobbyists, but it doesn't belong in the conversation with iPhones and Pixels from a security standpoint. It won't be making it onto the DoDIN APL any time soon.
fsflover 7mo ago
> Their microphone kill switch also doesn't prevent audio recording. Unless you provide some evidence, I will consider this false accusation. > They aren't open hardware despite many attempts to mislead people with the marketing. Who and where said they were open hardware? > extremely outdated proprietary fork of Android Which was freed and can run new Linux kernels now: https://github.com/the-modem-distro/pinephone_modem_sdk https://github.com/the-modem-distro/pinephone_modem_sdk and https://xnux.eu/devices/feature/modem-pp.html https://xnux.eu/devices/feature/modem-pp.html Your walls of text are disingenuous.
- handedness 7mo ago
  > Unless you provide some evidence, I will consider this false accusation. The line of thinking is, if you're so concerned about your device being compromised that you need to enable the mic kill switch (because of aforementioned lack of trust in the device), then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own. On a device that's that compromised one would have to physically power off every sensor on the device, and even then there would still be some things to consider. Air gaps are a thing for a reason, and yet some incredibly clever exploits have been demonstrated to jump that gap. Many components that aren't microphones, cameras or radios can be turned into cameras, microphones or radios pretty effectively. Still, I see the appeal of hardware switches as another practical layer against basic human factors, like a webcam lens cover adding another step beyond firing up the camera's permissions/appVM. But if we're being practical, a phone I can get wet is much more practical than a phone with physical hardware switches when I already have a high degree of trust the OS's ability to control sensors, and a low degree of rust in the OS's ability to control liquids and debris. > Which was freed and can run new Linux kernels now: Unfortunately that has kernel dependencies that haven't been updated in years. If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone. > Your walls of text are disingenuous. You've got the attention of one of the sharpest security minds on the planet and that is what you come up with? "Unless you provide some evidence, I will consider this false accusation." is bizarre, especially given your audience. You're capable of learning all this stuff on your own without asking everyone to do that for you. Regardless, nine sentences across two paragraphs isn't a wall of text. The guy took time out of his day to respond to banality and that's what he gets. It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?

by strcat 7mo ago

daneel_w 7mo ago

> Pinephones have entirely closed source baseband firmware. > The baseband firmware itself doesn't have any replacement available. Same with the Google Pixels and their Samsung Exynos modem. Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers. What will it be for the upcoming Motorola phone?

ysnp 7mo ago
Hi daneel, what would you like GrapheneOS to do while you develop your own formally verified, open hardware, open source firmware/OS baseband processor they can use? Sit on their hands doing nothing or making the best of the least worst options currently available?
- daneel_w 7mo ago
  The Pixels already are the best of the least worst options currently available. Anything new must categorically bring improvements, and the closed source firmware of the Pixels is a pressing point.
  - handedness 7mo ago
    That's reasonable, and I hope we get there. Qualcomm is an American company, and it sounds like the GrapheneOS team is working directly with them on developing the spec for this, including hardware MTE support. That's promising and I think could bring improvements over the current situation, if not open source modem firmware, unfortunately. I'm hoping to be surprised, though.
DANmode 7mo ago
> Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers Pixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of it?
- daneel_w 7mo ago
  Neither. It's great that the Pixels' baseband ACPU doesn't have free reign in system memory, but if we're gonna underline the deficient state of the cellular modem in the Pine Phone we should also remind ourselves that the firmware situation with the Pixels is an almost equally sore thumb.
  - DANmode 7mo ago
    It doesn’t feel equal to me, here in my real-world usecase.
  - handedness 7mo ago
    There's a lot of hand-wringing in this thread about Motorola's location, and a lot of support from a few for a modem made by a company headquartered in....Shanghai. If consistency here is what we claim to be pursuing, then let's actually pursue it. The opacity of the firmware situation isn't great on either, but one contains numerous excellent mitigations and is very proactively maintained, and the other is something that relies heavily on reverse engineering and community projects to even use. And it has a physical switch and has some physical distance between it and the CPU, both of which given the previous limitations are mostly theater, in practice. "My modem is so vulnerable it needs to be turned off during extra-important times, but I don't mind leaving it on during times that are merely important." As if a compromised OS can't just wait to exfil data. If your goal is to make it to Checkpoint Charlie and don't want the hassle of having to buy a new phone after you reach freedom, fine, but I haven't seen many well-articulated needs that would be satisfied by a hardware switch when everything behind that switch is filled with vulnerabilities. For my threat model, using the modern modem with a bounds sanitizer, an integer overflow sanitizer, stack canaries, control flow integrity, automatic initialization of stack variables, very active updates and a large commercial user base and a large market cap in part depending on it, makes a lot more sense. Google's highly lucrative ad tech business is what makes everyone nervous about anything Google, rightly so, but their share price would plummet if they were caught using Pixel hardware in nefarious ways, or did an unreasonably insufficient job in securing it. I'm not saying it's not possible that the modem is compromised, but for my threat model I have to put a lot into the possibility of an undetected backdoor inside a modem which is by all indications constructed very well, to make using a weird old modem known to be massively lacking in dozens of ways, running an OS with all kinds of issues, make more sense. And I say that as someone who tried the PinePhone at one point. Fun idea, but no commercial or state organization with an elevated risk profile would trust their data to a PinePhone as it stands. It's fun for hobbyists, but it doesn't belong in the conversation with iPhones and Pixels from a security standpoint. It won't be making it onto the DoDIN APL any time soon.

fsflover 7mo ago

> Their microphone kill switch also doesn't prevent audio recording. Unless you provide some evidence, I will consider this false accusation. > They aren't open hardware despite many attempts to mislead people with the marketing. Who and where said they were open hardware? > extremely outdated proprietary fork of Android Which was freed and can run new Linux kernels now: https://github.com/the-modem-distro/pinephone_modem_sdk https://github.com/the-modem-distro/pinephone_modem_sdk and https://xnux.eu/devices/feature/modem-pp.html https://xnux.eu/devices/feature/modem-pp.html Your walls of text are disingenuous.

handedness 7mo ago
> Unless you provide some evidence, I will consider this false accusation. The line of thinking is, if you're so concerned about your device being compromised that you need to enable the mic kill switch (because of aforementioned lack of trust in the device), then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own. On a device that's that compromised one would have to physically power off every sensor on the device, and even then there would still be some things to consider. Air gaps are a thing for a reason, and yet some incredibly clever exploits have been demonstrated to jump that gap. Many components that aren't microphones, cameras or radios can be turned into cameras, microphones or radios pretty effectively. Still, I see the appeal of hardware switches as another practical layer against basic human factors, like a webcam lens cover adding another step beyond firing up the camera's permissions/appVM. But if we're being practical, a phone I can get wet is much more practical than a phone with physical hardware switches when I already have a high degree of trust the OS's ability to control sensors, and a low degree of rust in the OS's ability to control liquids and debris. > Which was freed and can run new Linux kernels now: Unfortunately that has kernel dependencies that haven't been updated in years. If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone. > Your walls of text are disingenuous. You've got the attention of one of the sharpest security minds on the planet and that is what you come up with? "Unless you provide some evidence, I will consider this false accusation." is bizarre, especially given your audience. You're capable of learning all this stuff on your own without asking everyone to do that for you. Regardless, nine sentences across two paragraphs isn't a wall of text. The guy took time out of his day to respond to banality and that's what he gets. It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?