[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 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.

[nickpsecurity]

That's what OK Labs did before GD bought them:

https://web.archive.org/web/20111130031013/http://www.ok-lab...

CompSci folks have been doing it, too. Here's a paper describing the design style:

https://os.inf.tu-dresden.de/papers_ps/nizza.pdf

Genode OS Framework is only one I know building something like this in FOSS. The rest, esp used in phones, were commercial. One might port Android to something like it or seL4 with dynamic, resource management. Rewrite drivers or anything that's moved to kernel mode for performance in safe language or lots of verification tooling thrown at it.

[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.