[mlinksva]

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 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 and 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).