Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

grapheneos.org

Post reply on HN
Print view View original

21–30 of 186 posts

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#21

Post by brson »

ignoramous wrote: post #5

Creator of CopperheadOS [0] and now GrapheneOS, Daniel Micay, was a prolific contributor to rustlang-core [1] but did rub off the rustlang community the wrong way? If I'm not mistaken he has a history of contributing to Arch Linux, as well. What happened with CopperheadOS was unfortunate [2]. I hope Daniel [3] is able to work on GrapheneOS on his own terms [4]. The work that was done had garnered a lot of following a…

This project and its predecessor are so cool. I've been glad to see their continued progress.

It's probably not wise to post this, since I never talk about it publicly, he might not like it, and this thread should be about GrapheneOS, not Rust or myself. But with the mention of his Rust involvement and the history of CopperheadOS, I feel compelled at the moment to add some context and give him props.

He is an exceptionally skilled developer.

Some of his contributions to Rust were crucial. Of particular note, he re-designed Rust iterators to their current form. But he added to Rust so much more, both with his ideas and code.

And from what I recall he was in high school at the time. Amazing.

I happened to be the Rust team lead during much of his time contributing to the project, and a good deal of the blame for his departure belongs to me. It was a difficult learning experience for everyone.

It is totally fair to say that Rust would not be what it is today, both technically and socially, without him.

I was happy to see him rebound with CopperheadOS, and again here with GrapheneOS.

Good luck, Daniel.

(edited to remove some Rust cheerleading)

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#22

Post by ForHackernews »

ocdtrekkie wrote: post #18
letstrynvm wrote: post #10

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.

Indeed. I'm tired of each new attempt to fix Android and make it usable and safe. Apps written for Android are written to work with Google's expectations and assume the presence of Google's servers and proprietary APIs, and that's getting worse, not better. Librem is going the right way, and there are a handful of other companies working along the same path. Necunos is another I heard of as well: https://necunos.com/…

Also https://postmarketos.org/blog/2017/05/26/intro/ - "Aiming for a 10 year life-cycle for smartphones" using mainline Linux kernels.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#23

Post by strcat »

letstrynvm wrote: post #11
jtl999 wrote: post #9

Earlier quoted context omitted.

May have been an issue in the past. Daniel claims that modern Pixel devices (among others) use IOMMU to control which memory segments the baseband device can access, and if implemented correctly it should only allow what is necessary for device->driver communication. I do think more research is needed.

I was pretty amazed when I bought an MR200 lte-capable router that the LTE module actually runs its own personal Android discrete from the router cpu. https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections a…

The cellular, Wi-Fi / Bluetooth and NFC radios do receive firmware security updates. GrapheneOS isn't going to support devices without proper security support, which includes ongoing maintenance and security engineering / research for the firmware and drivers.

Focusing on the cellular baseband is missing the bigger picture. There are dozens of computers in modern personal computers running their own operating systems. Cellular basebands are very directly comparable to the Wi-Fi SoC. It's a mistake to think that the same things don't apply to Wi-Fi, especially when on so many devices it's much less contained than the cellular baseband. I'd recommend checking out https://googleprojectzero.blogspot.com/2017/04/over-air-expl... which is about exploiting the Wi-Fi SoC older generation device, which then provides full direct memory access since it wasn't meaningfully contained by the IOMMU. It was a configuration and driver coding issue, as the hardware was entirely capable of containing it but was unfortunately not set up to do it.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#24

Post by neilv »

duxup wrote: post #12
neilv wrote: post #3

A very condensed version of the messy CopperheadOS implosion is: https://en.wikipedia.org/wiki/CopperheadOS#History It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).

I always wondered what the backstory was there, but the internet is one of those places where if I heard to the real story I don't know if I'd know enough to belive it.

Edit: Voluntarily replaced with...

I had summarized public information and questions from as the implosion was happening, trying to be impartial and not voice my guesses as to what actually went on, and concluded that everyone should be given the benefit of the doubt, given all the unknowns.

But that impartiality could be upsetting to one of the parties (by bringing up things that, say, a good guy maybe can't talk about), and maybe this isn't the time, as people are recovering and moving forward.

At the same time, HN people might need to know some lessons from this noteworthy incident in development and privacy&security, since it should inform how we think about how other projects and startups can fail.

For example: a prominent security product can suddenly be compromised (e.g., in the sense of trusted security update mechanism broken, or a change in who controls updates), or a business partner can force out you and your intentions/stewardship of the product that you think depends on you being in the loop to not be evil, or a different business partner can delete very important keys, or (vaguely) this is another way it can be difficult to reconcile privacy&security goals with business ones.

These failures might be things we briefly consider as hypotheticals when planning or evaluating, but they do happen, in real life, on prominent efforts.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#25

Post by ocdtrekkie »

ForHackernews wrote: post #22
ocdtrekkie wrote: post #18

Earlier quoted context omitted.

Indeed. I'm tired of each new attempt to fix Android and make it usable and safe. Apps written for Android are written to work with Google's expectations and assume the presence of Google's servers and proprietary APIs, and that's getting worse, not better. Librem is going the right way, and there are a handful of other companies working along the same path. Necunos is another I heard of as well: https://necunos.com/…

Also https://postmarketos.org/blog/2017/05/26/intro/ - "Aiming for a 10 year life-cycle for smartphones" using mainline Linux kernels.

Yeah, and pmOS adds an interesting angle that they're adding legacy Android hardware to these companies' work on their own hardware, all running real Linux.

Note that Necunos' phone could actually be bought with pmOS preloaded as well, so you can really start to see how a few of these different projects are starting to work together and build on each other.

Hopefully we can have a truly FOSS mobile ecosystem in the next couple of years.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#26

Post by letstrynvm »

rst wrote: post #16
letstrynvm wrote: post #14

Earlier quoted context omitted.

I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.

Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.

That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning.

The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#27

Post by duxup »

neilv wrote: post #24
duxup wrote: post #12

Earlier quoted context omitted.

I always wondered what the backstory was there, but the internet is one of those places where if I heard to the real story I don't know if I'd know enough to belive it.

Edit: Voluntarily replaced with... I had summarized public information and questions from as the implosion was happening, trying to be impartial and not voice my guesses as to what actually went on, and concluded that everyone should be given the benefit of the doubt, given all the unknowns. But that impartiality could be upsetting to one of the parties (by bringing up things that, say, a good guy maybe can't talk ab…

Agreed. It is so strange how it just sort of "happened" generally I don't think such things usually just happen out of nowhere, so half the story I think would how everyone came together to work together and then end up in a situation that was as apocalyptic as far as how it played out for the project.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#29

Post by temptemptemp111 »

Mediterraneo10 wrote: post #8
robotbikes wrote: post #4

Earlier quoted context omitted.

From the link- "In the current early stage of the project, GrapheneOS provides production releases for the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL. It will support other devices in the future, but devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventuall…

Don’t even those phones feature a cellular modem that shares memory with the CPU? In that case, they remain insecure.

Yep!

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#30

Post by strcat »

neilv wrote: post #3

A very condensed version of the messy CopperheadOS implosion is: https://en.wikipedia.org/wiki/CopperheadOS#History It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).

The Android Open Source Project is the only viable starting point. I don't know what else you would suggest. It has solid privacy and security as a baseline already, unlike other mobile or desktop Linux-based operating systems. There's also a huge amount of public security research targeting it for both offensive and defensive work. Moving to the desktop Linux stack would drastically set back both privacy and security. It would take a decade of work by dozens of programmers just to catch up, and the goal of the project is advancing the status quo rather than trying to play catch up to it for years. The goal is not creating a new ecosystem for applications and convincing developers to target it, especially if it would be for no particular reason. It needs an existing application ecosystem, so Android app compatibility is of utmost importance.

Having a massive monolithic kernel at the core of the operating system written entirely in a memory unsafe language is obviously a huge problem, and will need to be addressed over the long term. It's an increasingly blatant weakness, and the enormous amount of ongoing work that has gone into userspace doesn't translate well to the kernel. Developing increasingly more sophisticated mitigations helps a bit, but it can't solve the fundamental issues with the choice of language, architecture or development process. Linux ultimately isn't a viable choice for creating a system with decent security. However, Linux compatibility is part of Android compatibility and is essential. That means the Linux kernel either has to be kept around in virtual machines or replaced with a compatibility layer on top of a microkernel. https://github.com/google/gvisor is an existing project which could be ported to arm64, expanded as needed and adjusted to run on top of another kernel but it doesn't need to be the starting point. It's usually a good idea to start from an existing base like this and try to land everything needed upstream though, rather than burning far more resources starting from scratch and losing out on the shared benefits from collaboration with a larger community.

Using virtualization is a nearer term goal, with a compatibility layer as a much longer term aspiration. There's not much written about the roadmap on the linked page, but this stuff is actually mentioned, and I'd recommend checking it out before wrongly assuming that the goal is simply having a hardened fork of AOSP. There has already been substantial work on experimenting with integrating virtualization for app containment, although containing user profiles would be another approach and potentially more useful.

Post reply on HN