diff --git a/static/build.html b/static/build.html index 9ca06fe0..f3c55402 100644 --- a/static/build.html +++ b/static/build.html @@ -25,7 +25,7 @@ - +
diff --git a/static/faq.html b/static/faq.html index 4251e3cc..d285ad8a 100644 --- a/static/faq.html +++ b/static/faq.html @@ -25,7 +25,7 @@ - +
@@ -111,6 +111,7 @@
  • Does GrapheneOS provide Factory Reset Protection?
  • Why aren't my favorite apps bundled with GrapheneOS?
  • Who owns the GrapheneOS code and how is it licensed?
    • +
  • What is the roadmap for GrapheneOS?
    • @@ -942,6 +943,41 @@ usage licensing. Great care was taken to avoid pulling in anything that was not solely owned by Daniel Micay, which was the case for nearly everything in the project.

    + +
    +

    What is the roadmap for GrapheneOS?

    + +

    To get an idea of the near term roadmap, check out the + issue trackers. The vast majority of the + issues filed in the trackers are planned enhancements, with care taken to make sure + all of the issues open in the tracker are concrete and actionable.

    + +

    In the long term, GrapheneOS aims to move beyond a hardened fork of the Android + Open Source Project. Achieving the goals requires moving away from relying on 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.

    + +

    The initial phase for the long-term roadmap of moving away from the current + foundation will be to deploy and integrate a hypervisor like Xen to leverage it for + reinforcing existing security boundaries. Linux would be running inside the virtual + machines at this point, inside and outside of the sandboxes being reinforced. In the + longer term, Linux inside the sandboxes can be replaced with a compatibility layer + like gVisor, which would need to be ported to arm64 and given a new backend alongside + the existing KVM backend. Over the longer term, i.e. many years from now, Linux can + fade away completely and so can the usage of virtualization. The anticipation is that + many other projects are going to be interested in this kind of migration, so it's not + going to be solely a GrapheneOS project, as demonstrated by the current existence of + the gVisor project and various other projects working on virtualization deployments + for mobile. Having a hypervisor with verified boot still intact will also provide a + way to achieve some of the goals based on extensions to Trusted Execution Environment + (TEE) functionality even without having GrapheneOS hardware.

    + +

    Hardware and firmware security are core parts of the project, but it's currently + limited to research and submitting suggestions and bug reports upstream. In the long + term, the project will need to move into the hardware space.

    +