security/hakurei.app
security/hakurei.app
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

move roadmap to FAQ

Browse Source
This commit is contained in:
Daniel Micay 2020-12-16 23:06:00 -05:00
parent 0145284791
commit 6aa5c68d82
5 changed files with 42 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
static/build.html
View File

@ -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>

38
static/faq.html
View File

@ -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>

30
static/index.html
View File

@ -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">

1
static/redirect.js
View File

@ -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"],

2
static/usage.html
View File

@ -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>