diff options
| author | Daniel Micay <danielmicay@gmail.com> | 2020-12-16 23:06:00 -0500 |
|---|---|---|
| committer | Daniel Micay <danielmicay@gmail.com> | 2020-12-16 23:06:00 -0500 |
| commit | 6aa5c68d8252789482a0b475f34b0623c7990fbe (patch) | |
| tree | b9048d2773e157367d3de6d864254a0fe093706a /static/faq.html | |
| parent | 01452847910afcbc8452afa6bb6bb8bb57d12af5 (diff) | |
move roadmap to FAQ
Diffstat (limited to 'static/faq.html')
| -rw-r--r-- | static/faq.html | 38 |
1 files changed, 37 insertions, 1 deletions
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 @@ <link rel="manifest" href="/manifest.webmanifest"/> <link rel="canonical" href="https://grapheneos.org/faq"/> <link rel="license" href="/LICENSE.txt"/> - <script type="module" src="/redirect.js?6"></script> + <script type="module" src="/redirect.js?7"></script> </head> <body> <header> @@ -111,6 +111,7 @@ <li><a href="#anti-theft">Does GrapheneOS provide Factory Reset Protection?</a></li> <li><a href="#bundled-apps">Why aren't my favorite apps bundled with GrapheneOS?</a></li> <li><a href="#copyright-and-licensing">Who owns the GrapheneOS code and how is it licensed?</a></li> + <li><a href="#roadmap">What is the roadmap for GrapheneOS?</a></li> </ul> </nav> @@ -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.</p> </article> + + <article id="roadmap"> + <h2><a href="#roadmap">What is the roadmap for GrapheneOS?</a></h2> + + <p>To get an idea of the near term roadmap, check out the + <a href="/contact#reporting-issues">issue trackers</a>. 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.</p> + + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + </article> </main> <footer> <a href="/"><img src="/logo.png" width="512" height="512" alt=""/>GrapheneOS</a> |