Skip to content

Commit 470a5bf

Browse files
Ganwtrsthestinger
authored andcommitted
Update virtualization roadmap
1 parent 4353e9f commit 470a5bf

File tree

1 file changed

+14
-12
lines changed

1 file changed

+14
-12
lines changed

static/faq.html

Lines changed: 14 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1789,18 +1789,20 @@ <h2><a href="#roadmap">What is the roadmap for GrapheneOS?</a></h2>
17891789
isolation.</p>
17901790

17911791
<p>The initial phase for the long-term roadmap of moving away from the current
1792-
foundation will be to deploy and integrate a hypervisor like Xen to leverage it for
1793-
reinforcing existing security boundaries. Linux would be running inside the virtual
1794-
machines at this point, inside and outside of the sandboxes being reinforced. In the
1795-
longer term, Linux inside the sandboxes can be replaced with a compatibility layer
1796-
like gVisor, which would need to be ported to arm64 and given a new backend alongside
1797-
the existing KVM backend. Over the longer term, i.e. many years from now, Linux can
1798-
fade away completely and so can the usage of virtualization. The anticipation is that
1799-
many other projects are going to be interested in this kind of migration, so it's not
1800-
going to be solely a GrapheneOS project, as demonstrated by the current existence of
1801-
the gVisor project and various other projects working on virtualization deployments
1802-
for mobile. Having a hypervisor with verified boot still intact will also provide a
1803-
way to achieve some of the goals based on extensions to Trusted Execution Environment
1792+
foundation will be to deploy and integrate
1793+
<a href="https://source.android.com/docs/core/virtualization/architecture">pKVM</a>
1794+
and CrosVM, reinforcing existing security boundaries. The Android Open Source
1795+
Project has been making significant progress on this front, so our next milestone is
1796+
to securely deploy Android apps using this virtualization setup. In the longer term,
1797+
Linux inside the sandboxes can be replaced with a compatibility layer like gVisor,
1798+
which would need to be given a new backend alongside the existing KVM backend. Over
1799+
the longer term, i.e. many years from now, Linux and the usage of virtualization can
1800+
fade away completely. The anticipation is that many other projects are going to be
1801+
interested in this kind of migration, so it's not going to be solely a GrapheneOS
1802+
project; this is demonstrated by the current existence and development of gVisor and
1803+
pKVM, as well as various other projects working on virtualization deployments for
1804+
mobile. Having a hypervisor with verified boot still intact will also provide a way
1805+
to achieve some of the goals based on extensions to Trusted Execution Environment
18041806
(TEE) functionality even without having GrapheneOS hardware.</p>
18051807

18061808
<p>Hardware and firmware security are core parts of the project, but it's currently

0 commit comments

Comments
 (0)