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 | |
| parent | 01452847910afcbc8452afa6bb6bb8bb57d12af5 (diff) | |
move roadmap to FAQ
| -rw-r--r-- | static/build.html | 2 | ||||
| -rw-r--r-- | static/faq.html | 38 | ||||
| -rw-r--r-- | static/index.html | 30 | ||||
| -rw-r--r-- | static/redirect.js | 1 | ||||
| -rw-r--r-- | static/usage.html | 2 |
5 files changed, 42 insertions, 31 deletions
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 @@ <link rel="manifest" href="/manifest.webmanifest"/> <link rel="canonical" href="https://grapheneos.org/build"/> <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> 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> diff --git a/static/index.html b/static/index.html index c32032f3..440a9947 100644 --- a/static/index.html +++ b/static/index.html @@ -25,7 +25,7 @@ <link rel="manifest" href="/manifest.webmanifest"/> <link rel="canonical" href="https://grapheneos.org/"/> <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> @@ -223,33 +223,7 @@ <section id="roadmap"> <h2><a href="#roadmap">Roadmap</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> + <p>See <a href="/faq#roadmap">the FAQ section on the roadmap</a>.</p> </section> <section id="device-support"> diff --git a/static/redirect.js b/static/redirect.js index 54c5be82..8ef4345d 100644 --- a/static/redirect.js +++ b/static/redirect.js @@ -10,6 +10,7 @@ const redirects = new Map([ ["/#device-support", "/faq#device-support"], + ["/#roadmap", "/faq#roadmap"], ["/usage#default-connections", "/faq#default-connections"], ["/releases#marlin-stable", "/faq#legacy-devices"], ["/releases#sailfish-stable", "/faq#legacy-devices"], diff --git a/static/usage.html b/static/usage.html index a8ae5580..1f7f8bf4 100644 --- a/static/usage.html +++ b/static/usage.html @@ -25,7 +25,7 @@ <link rel="manifest" href="/manifest.webmanifest"/> <link rel="canonical" href="https://grapheneos.org/usage"/> <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> |