
GrapheneOS – A privacy and security-focused mobile OS with Android compatibility - yegortimoshenko
https://grapheneos.org/#
======
letstrynvm
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/](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.

~~~
yegortimoshenko
Librem 5 isn't going to be particularly security-focused: no attestation, no
trusted boot, most userspace programs are written in memory unsafe languages
like C, with no extra effort memory corruption mitigations. Also, Flatpak
offers a permission system that's very limited compared to Android.

~~~
pjmlp
While with each Android interaction, Google locks down the amount of C and C++
code that gets exposed to outside world.

[https://android-developers.googleblog.com/2019/05/queue-
hard...](https://android-developers.googleblog.com/2019/05/queue-hardening-
enhancements.html?m=1)

As such I have a very hard time believing that Librem with be as secure as
modern Android.

~~~
mbrumlow
There is security, and then there is freedom. You can have the most secure
system in the world -- but if there are state sponsored, or company back back
doors it means nothing.

In FOSS initiatives spent ages building fee and and open software, combating
proprietary systems and software that they had no control over.

All that would be loss just to give it up now that we have moved from PCs to
phones....

I for one want control over all the software I run on hardware I own. I am not
sure why we are so willing to give that control up simply because the platform
changed.

~~~
KirinDave
> There is security, and then there is freedom. You can have the most secure
> system in the world -- but if there are state sponsored, or company back
> back doors it means nothing.

Okay, so you're saying: "If a backdoor is present than your security
prioritization doesn't matter, the result is bad." I understand, but:

1\. If there is a back door in open source code that goes unnoticed (and it
certainly does) because of persistent but bad practices in the open source
community (e.g., a stubborn refusal to stop using C-like memory management
semantics and primitives when dealing with untrusted inputs), then why don't
said accidentaly backdoors invalidate the open source work?

2\. Does "control" actually matter in the context of AOSP? Strictly speaking,
you have essentially everything you need up utill you hit the hardware
drivers. You can easily rewrite that to your hearts content.

3\. Given Librem's recently move into commodity-based social products (and the
poop-from-great-height attitude they initially adopted), are you genuinely
sure that they're actually trustworthy actors? If they're coerced, how will yu
attest that they never injected a deeply subtle backdoor on millions of lines
of code which you'd like to be unique and less scrutinized?

I can't really work out why you feel the way you do, so I ask these questions.

~~~
soraminazuki
> persistent but bad practices in the open source community (e.g., a stubborn
> refusal to stop using C-like memory management semantics and primitives when
> dealing with untrusted inputs)

This applies to the _entire industry_. It's not something specific to the open
source community. It's also extreme to call the use of C as "bad practice," as
any language has its own strengths and weaknesses.

~~~
pjmlp
Not the entire industry, as many companies have thankfully moved on from plain
old C, or at very least reduced its use quite considerably.

BSD/Linux derived FOSS is still the C stronghold.

The Morris worm was in 1988, since then C has collected enough CVEs due to
memory corruption issues to consider its use bad practice.

Something that even Apple, Google and Microsoft security reports now advise
against, and with Google actively engaging into taming C's usage in Linux
kernel.

~~~
Nursie
> BSD/Linux derived FOSS is still the C stronghold.

Oh that's ok then, it's not like that accounts for most of the world's server
and embedded infrastructure, open or otherwise...

~~~
orbifold
The operating system is only a tiny fraction of commercial code out there most
of which is either written in (more) memory safe languages like Java, C# or
C++. SAPs code base alone is 1 billion lines of mostly C++ and their own
proprietary scripting language.

~~~
Nursie
Wait, is C++ memory safe?

I know they've introduced a lot of ways that memory management becomes easier
or automatic, but I'm not sure you can call it "memory safe" can you?

~~~
pjmlp
Not to the extent that it is tainted by C's copy-paste compatibility.

Still it does provide a stronger type system, proper string, vectors,
reference paramenters and strong type enumerations, to prevent a large amount
of C security exploits.

C++ teams that care about security do use such features and respective static
analysers on their CI/CD to enforce them.

While it doesn't cover everything, it is much safer than plain C.

Ideally, we will reach a state where both C and C++ get nuked, or ISO C++ just
drops its C copy-paste compatibility, which in the end means it is anyway
easier to switch to something else.

However that process will take decades, and is hampered by relying on POSIX
based systems.

------
neilv
A very condensed version of the messy CopperheadOS implosion is:
[https://en.wikipedia.org/wiki/CopperheadOS#History](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).

~~~
strcat
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](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.

~~~
eeZah7Ux
> Linux ultimately isn't a viable choice for creating a system with decent
> security.

Stop spreading FUD. In this conversation we are talking about phones filled
with bloatware that spies on the user in every instant and you nitpick about
memory safety in the kernel.

~~~
strcat
I'm not spreading FUD, and the conversation isn't about what you claim.
Talking about the lack of basic security on existing operating systems based
on monolithic kernels written in memory unsafe languages is hardly nitpicking.
It's the kind of stuff that GrapheneOS is all about... which is what this
entire is about.

------
ignoramous
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 and there's hope, given his exploits in the past,
that he'd be able to steer this non-profit to heights where industry leaders
building SilentCircle [5] and CyanogenMod failed.

Sure will be following the project from afar and routing for its success.

Good luck Daniel.

[0]
[https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodby...](https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodbye/)

[1]
[https://news.ycombinator.com/item?id=9551937#9552769](https://news.ycombinator.com/item?id=9551937#9552769)

[2]
[https://news.ycombinator.com/item?id=17289536](https://news.ycombinator.com/item?id=17289536)

[3]
[https://news.ycombinator.com/user?id=strcat](https://news.ycombinator.com/user?id=strcat)

[4]
[https://news.ycombinator.com/item?id=19501643#19559969](https://news.ycombinator.com/item?id=19501643#19559969)

[5]
[https://news.ycombinator.com/item?id=12047219](https://news.ycombinator.com/item?id=12047219)

~~~
brson
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)

~~~
yokohummer7
I remember him as a very Torvalds-like person, for better or worse.

I wanted him to stay a little more around the Rust 1.0 era because I thought
as many warts as possible should have been fixed before the backward
compatibility guarantee was made, but he left too early.

Didn't know about the CopperheadOS incident, too bad such a situation happened
to him. Good to see it's kinda resolved now.

------
racuna
Also, [https://postmarketos.org/](https://postmarketos.org/) is a good project
too.

~~~
neilv
PostmarketOS seems the most promising effort for a truly open and affordable
handheld OS with mainline kernel and other good practices.

And there's also a useful incremental path for evolution, that starts with a
familiar GNU/Linux and moves gradually towards handheld tweaks (UI, power,
devices, apps).

It's important to be upfront that PostmarketOS is not yet viable as a daily
driver, or people will feel they wasted their time looking at it. What it
really needs is programmers, like the earlier Linux ones, who will power
through the pain of getting things working well, and stick with it for months,
as a labor of love.

~~~
Dunedan
PostmarketOS reminds me a lot about the approach Openmoko
([https://en.wikipedia.org/wiki/Openmoko](https://en.wikipedia.org/wiki/Openmoko))
took way back over a decade ago, except that they did have to build the
hardware as well.

~~~
neilv
There've been several such prominent open source handheld projects in the last
20 years. PostmarketOS seems the most viable, IMHO, because it emphasizes the
old Linux (and GNU) principles of getting working on lots of available
hardware, with true open source, mainlined. (Separately, it also potentially
builds on a wealth of GNU/Linux stuff that there's no good reason shouldn't
have a lot of commonality between desktop and handheld.)

------
mlinksva
[https://grapheneos.org/#roadmap](https://grapheneos.org/#roadmap) is pretty
interesting:

> Details on the roadmap of the project will be posted on the site in the near
> future. In the long term, it aims to move beyond a hardened fork of the
> Android Open Source Project. Achieving the goals requires moving away from
> relying the Linux kernel as the core of the OS and foundation of the
> security model. It needs to move towards a microkernel-based model with a
> Linux compatibility layer, with many stepping stones leading towards that
> goal including adopting virtualization-based isolation.

~~~
strcat
Strengthening the security with virtualization is something that's in the
early stage of experimentation and research and will be a long-term project.
Over the long term though, the goal is moving away from having the Linux
kernel completely other than as the native API / ABI for apps. Projects like
[https://github.com/google/gvisor](https://github.com/google/gvisor) are very
promising in that regard even if they end up playing no part in how this
eventually happens for GrapheneOS. A clearer and much more detailed roadmap
will be posted soon. The site is still very newly created and barely has any
information about the project.

Essentially, the goal for the project is for it to be an OS compatible with
Android apps, using the Android Open Source Project software stack to run
them, but the underlying base can become whatever is most suited to the task.
For now, the most practical approach is using virtualization to reinforce the
app sandbox and user profiles. Eventually, the virtual machines can drop
having their own Linux kernels (see gVisor as an example of this). In the very
long term, the Linux kernel at the core of the OS could eventually go away
too.

I'd recommend checking out the standalone projects like
[https://github.com/GrapheneOS/hardened_malloc](https://github.com/GrapheneOS/hardened_malloc)
and
[https://github.com/GrapheneOS/Auditor](https://github.com/GrapheneOS/Auditor)
for an idea of what the project is focused on doing. The hardened_malloc
implementation supports other operating systems, as does Auditor, which
supports verifying the stock OS on many mobile devices (they need to be added
one-by-one to the internal database based on users submitting attestation
samples with the app) and CalyxOS in addition to GrapheneOS.

The OS project itself is still in the early stage of reviving it, porting over
past work and getting the basics done. It's very focused on the infrastructure
and low-level work right now. Working on the higher level features that are
more user facing and bundling various apps, etc. is not a priority right now.
It doesn't even bundle F-Droid right now, because it's not quite at the point
where bundling any third party apps makes sense. It also needs to be
determined how to best approach that. A lot of these things will also be done
in collaboration with other projects like CalyxOS, with GrapheneOS focusing
more on low-level security hardening. CalyxOS is primarily working on areas
like the backup service implementation and various other higher-level
services, and a lot of this will be used by GrapheneOS too.

~~~
oscargrouch
I think if you dont have a strong opinion about it, this is exactly what they
are trying to achive with Zircon/Fuchsia kernel.

A micro-kernel, with a linux virtualization layer, being abble to run Linux
executables as if they were native.

My hunch is that in the long term, Google will probably use Zircon as the
'first-level' kernel, and run the android apps using some emulation layer.

Maybe it could be the answer for what you are trying to accomplish, without
having to create a whole micro-kernel OS from scratch, while at the same time
benefiting from whats already there.

I bet that with such a thing in place, the Linux kernel could totally go away,
with only a emulation layer in place if you want to.

~~~
pjmlp
Google has already kind of achieved that with ChromeOS, each Linux executable
runs in a sandbox, specially tailored for it.

It can only see hardware, files and processes that the user allows to as well.

It was written in Rust.

Check the ChromeOS support for Linux talk at Google IO.

~~~
oscargrouch
I have checked this earlier. Its pretty cool stuff, but its more in the
direction of userspace emulation like what GVisor do.

The OP expressed he wanted to use (or create idk) a micro-kernel based OS, and
that in the end he would like to scrap the Linux kernel.

Of course the solution you are pointing out will deliver in one of those axis,
but the solution im pointing out would deliver in both, Linux
emulation/sandboxing and a micro-kernel based OS controlling all of this.

I just think that the direction Fuchsia is going, has a little bit more to do,
to what he is trying to achieve.

But he can totally mix the 'syscall proxy' solution of ChromeOS and a micro-
kernel, even if this would still be Zinc or something else. And depending on
the goal, maybe having this in userspace level would make more sense. He just
need a good and flexible IPC communication (like the one in Chrome, or
something on the kernel level).

------
ThinkBeat
It supports the Google Pixel range of phones only so far.

So in order to get that is more secure and more independent from Google I have
to buy a Google phone?

~~~
yegortimoshenko
There are not that many phone manufacturers that even allow you to change the
trust anchor (which makes any of this even remotely possible). For example,
Samsung uses e-fuses to burn in their signing key, rewriting recovery will
permanently trip their attestation (Knox); other manufacturers use similar
practices. Pixels are one of the only currently available phones with user-
controlled trusted boot in mind.

~~~
strcat
There are more devices supporting this than there used to be though.
[https://grapheneos.org/#device-support](https://grapheneos.org/#device-
support) explains that it's going to support other devices. It doesn't support
the Pixel 3a and Pixel 3a XL yet either. Supporting each device is a lot of
work, and other devices will need to be carefully chosen. It would be harmful
to make bad choices about device support and encourage people to buy insecure
devices with too many issues that can't be fixed with another OS.

~~~
indolering
Has Project Treble helped in this area?

------
danvittegleo
For anyone interested in doing their own customizable builds of AOSP for Pixel
devices check out: [https://github.com/dan-v/rattlesnakeos-
stack](https://github.com/dan-v/rattlesnakeos-stack). This doesn't have any of
the security hardening features of GrapheneOS, but does have some of the same
security properties like verified boot, OTA software updates that included
updated firmware/drivers, support for remote attestation, etc.

------
xaduha
Stock-ish Android that gets updates is good enough for me. I'm looking forward
to wider support of U2F over NFC in general though, I don't keep data on the
phone itself.

You can buy a contactless smartcard for $15 each and install this on it
[https://github.com/tsenger/CCU2F](https://github.com/tsenger/CCU2F)

------
rplnt
What does it matter if you are still running proprietary software with direct
memory and CPU access on your network, camera, ...

Android can give you privacy and enough security for most people. This can't
add much more as long as its running on the same devices.

This is a great effort and I support it, but let's not imagine this will make
our phones that much more secure.

~~~
strcat
Open source is a development model and doesn't have magical privacy and
security properties. An iPhone is going to remain the best overall option for
privacy and security for the near future, especially for users that aren't
very technical. That's not really in spite of it being almost entirely
proprietary but rather that's something quite orthogonal to it. GrapheneOS
aims to provide a much more private and secure option down the road, but it's
trying to do that based on merit rather than by claiming that being open
source makes it better. Either way, the any ARM SoC is going to be a
_massively_ complex set of proprietary hardware / firmware / microcode. An
open hardware SoC wouldn't provide inherently better privacy or security, and
unlike software you wouldn't even be able to reproduce the build and verify
that it matches what it's supposed to be. In reality, that provides very
little for software, because sources are full of vulnerabilities and it being
open source doesn't magically fix them. A maliciously inserted backdoor
designed to be stealthy would be indistinguishable from those, and it's nearly
impossible to know how many of the vulnerabilities being fixed in software
were intentionally inserted backdoors, if any. A sophisticated attacker in a
position to insert a backdoor into hardware or software could just use the
existing vulnerabilities, and if they did insert a backdoor how would you
distinguish it from one of those?

Components with DMA can be contained by IOMMU, and that's the industry
standard today. However, you seem to be implying that backdoors are being
inserted into non-CPU SoC components, and it's very hard to understand the
threat model you're applying to this. Why would there even be a backdoor
inserted into an SoC component like the image processor, which is contained by
the IOMMU, rather than the CPU? These SoC components aren't third party
components. They're on the same die as the CPU and come with it. That doesn't
mean they can freely access all memory... but it does mean that supply chain
attacks targeting them would generally be able to target the CPU instead.

If a hardware component is compromised, an attacker would target the driver
and gain code execution in the Linux kernel via an exploit. The Linux kernel
is a weak target (monolithic - no internal security boundaries, fully written
in a memory unsafe language) and drivers are rarely well hardened against
attacks from hardware since developers have a tendency to trust it and to not
apply an adversarial model towards it as they do with userspace. They don't
need unrestricted DMA access, and proper IOMMU setup keeps them from having
that. Having DMA does not mean having full control over all memory. Not having
DMA doesn't mean that the component is well isolated. Whether or not the
component is on the same die is totally orthogonal to whether it has DMA
access. These are common misconceptions, and are being abused by dishonest
marketing to trick people.

> Android can give you privacy and enough security for most people.

Some of that is due to the improvements landed upstream based on the work in
this project.

> This can't add much more as long as its running on the same devices.

I don't agree with that at all. It can't improve the security of firmware
directly, but it can certainly improve the isolation of it by auditing and
improving IOMMU configuration along with hardening the drivers. It also won't
be supporting devices without decent IOMMU support and firmware security
updates. The project has also reported various firmware security issues to the
relevant companies over the years of the project, so that's an indirect way of
improving them.

A large portion of the project will also be on app layer projects like
[https://github.com/GrapheneOS/Auditor](https://github.com/GrapheneOS/Auditor)
usable on the stock OS and other operating systems. Auditor /
AttestationServer support the stock OS on a bunch of devices, along with
CalyxOS and GrapheneOS. Other apps will generally be more portable, but in
this case it has to have a database of the verified boot key fingerprints and
other device properties. The verified boot key is the only information
included in the signed hardware attestation data that it can use to
distinguish between devices which it needs to do in order to show the device
model and apply different checks based on the device. That's why devices need
to be added to Auditor one-by-one based on users submitting sample
attestations with the app.

~~~
nickpsecurity
"They're on the same die as the CPU and come with it. That doesn't mean they
can freely access all memory... but it does mean that supply chain attacks
targeting them would generally be able to target the CPU instead."

I don't disagree with your overall post. I do want to add that there's a good
reason to not put the backdoor in the CPU: it's main place they'll look with
plenty of people capable of spotting it. The guy that taught me about hardware
subversion years ago preferred hiding stuff in analog parts of mixed-signal
ASIC's. He said digital people neither saw it nor understood it. He and others
taught me about how the two can interact in invisible ways where analog or RF
portions might pick up leaks. So, deniability is maximum if it's some kind of
analog or RF part of a chip. He claimed to have never found backdoors but that
he and others used this for I.P. obfuscation a lot.

I do like the IOMMU and firmware work. There's a lot of custom I.P. to build
before being competitive with one of high-end SOC's. One thing I considered
about trying to make an open phone is whether a company with money could just
pay for Snapdragon to be integrated with the RISC-V cores. Modify RISC-V core
to use microcode for security updates and product enhancements. Put security
barriers in key places so Snapdragon I.P. is a little less dangerous or can
even be powered off component by component. Then, if the agreement gets more
data on hardware, use that with secure, development practices to make robust
drivers. Include method for secure boot and update that still allows user to
put their own stuff on the phone if they choose.

What you think?

EDIT: In case it wasn't clear, I know there's stuff like IOMMU's in
Snapdragon. I'd just prefer an independent, security-focused company to be
making those components. Sort of a check against incompetence or malice on
Snapdragon's end.

------
dvduval
Would this be something Huawei might get into?

~~~
_Ender
Huawei could probably do something similar, however they still can't access
the Google Play Store and such, therefore leaving them in a problematic area.
For instance, though somewhat substantial, the Amazon store is quite pitiful
in comparison to Google Play. Huawei could attempt to make a store but it
won't have the world of apps that already exist on the Play Store.

This would work in China though, since they don't have the Play Store in the
first place.

------
_Ender
"Android compatibility" implies that it's something entirely new. It appears
to be an Android fork that simply hasn't done away with compatibility. There
are neat ideas and all, but the title implies that it's something that it
isn't.

Lastly, I wonder how this will do over time considering Fuschia.

~~~
strcat
It's not implied that it's something completely new, although a dozen of the
sub-projects are new projects rather than forks of existing ones. The overall
project is not simply a fork of the Android Open Source Project with
hardening. That's a subset of the work, and a big part of it. I also added a
paragraph to the placeholder index page clarifying the longer-term plans with
virtualization:
[https://grapheneos.org/#roadmap](https://grapheneos.org/#roadmap).

GrapheneOS includes sub-projects including standalone projects like
[https://github.com/GrapheneOS/Auditor](https://github.com/GrapheneOS/Auditor)
and
[https://github.com/GrapheneOS/hardened_malloc](https://github.com/GrapheneOS/hardened_malloc)
that are portable to other operating systems. This also applies to a lot of
work that's under active development and not yet published as part of the
stable releases.

It intentionally doesn't stick to the Compatibility Definition Document /
Compatibility Test Suite requirements required to be Android, so it can't be
referred to as Android, but rather it's an OS with Android app compatibility.
It preserves what's actually needed for compatibility in practice, while not
being strictly bound by those requirements. The intentional deviations from
these are documented, and there are a bunch of them.

> Lastly, I wonder how this will do over time considering Fuschia.

If it ends up shipping as a replacement for the core OS, with Android running
in a virtual machine or on top of a compatibility layer like gVisor, that
would just mean that there's a better base to build on than before. All of the
work done by the project would still be relevant in a future like that. I'm
not so sure that's truly going to happen though.

~~~
_Ender
I get that, and the site doesn't imply that it's something new, but I simply
found the title of the post to be such.

Fair enough though.

>If it ends up shipping as a replacement for the core OS, with Android running
in a virtual machine or on top of a compatibility layer like gVisor, that
would just mean that there's a better base to build on than before. All of the
work done by the project would still be relevant in a future like that. I'm
not so sure that's truly going to happen though.

I see.

------
markstos
I can see what the focus is, but I couldn't find a page that clearly spelled
out differences with AOSP. I realize that's a missing target, but as a
potential user it's interesting to know how it's going to be different than
stock Android (beyond what the "focus" is).

------
nerd7473
I need to try this, I also need to get a Librem 5, and build my project for
it. Anyone know of any good projects for replacing google services with FOSS
services that do the same basic things?

------
techsin101
I shouldnt be commenting. But os with new kernel like chrome os would be ideal
for security, privacy and performance. Only thing left is open hardware not
sure how to go about it.

------
julienfr112
Is that like the real thing (graphene) and can do anything but go out of the
lab ?

------
samirm
how does this compare with something like microG?

~~~
0xdeadb00f
It doesn't compare because microG isn't an Android "ROM" \- you can't compare
the two.

~~~
black_puppydog
You most certainly can!

Microg is a (very welcome!) band-aid for the fact that the android ecosystem
is critically dependent on a proprietary piece of software called play
services.

PMO is a different, libre, OS and ecosystem that doesn't have that problem to
begin with since it is truly a Linux (as opposed to AOSP) and truly free (as
opposed to android's "can read most code but Google holds all the cards")

~~~
strcat
There's a far larger app ecosystem for Android without Play Services than any
other mobile OS. It's very odd to try to claim that it doesn't have that
problem. Android is truly a Linux distribution too, and is truly free
software. You can promote your preferred mobile OS without making misleading
claims.

------
tdxcbkif
How does graphene compare to linage os?

------
AstralStorm
Security focused and Android in the same sentence? All I can say is good luck
with various firmware, custom services and drivers.

~~~
robotbikes
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 eventually be engaging in hardware and firmware
level improvements rather than only offering suggestions and bug reports
upstream for those areas."

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

~~~
jtl999
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.

~~~
letstrynvm
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](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 and futz with
any traffic, eg, deny main OS updates until it can attack it via an unpatched
vuln. TLS is good but it'd only take one hhtp connection through unpatched
webview.

~~~
strcat
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...](https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-
broadcoms-wi-fi_11.html) 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.

