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

overhaul APEX documentation

Browse Source
This commit is contained in:
Daniel Micay 2021-12-02 05:38:30 -05:00
parent a8d775c749
commit 658baa894b
1 changed files with 20 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
static/build.html
View File

@ -652,26 +652,28 @@ cd ../..</pre>
<section id="enabling-updatable-apex-components"> <section id="enabling-updatable-apex-components">
<h4><a href="#enabling-updatable-apex-components">Enabling updatable APEX components</a></h4> <h4><a href="#enabling-updatable-apex-components">Enabling updatable APEX components</a></h4>
<p>GrapheneOS disables updatable APEX components for the officially supported devices <p>GrapheneOS uses the <code>TARGET_FLATTEN_APEX := true</code> format to
and targets inheriting from the mainline target, so APEX signing keys are not needed include APEX components as part of the base OS and disables support for
and this section can be ignored for unmodified builds.</p> out-of-band APEX component updates. This reduces complexity and attack
surface along with simplifying key management since there aren't a bunch
of additional components to sign. GrapheneOS has no use for out-of-band
updates to APEX components since we update the OS for each device and
don't need partial out-of-band updates for portable components.</p>
<p>GrapheneOS uses the <code>TARGET_FLATTEN_APEX := true</code> format to include APEX <p>APEX components that aren't flattened are a signed APK (used to verify
components as part of the base OS without supporting out-of-band updates.</p> updates) with an embedded filesystem image signed with an AVB key (for
verified boot). Our release signing scripts has support for signing
non-flattened APEX components with the releasekey and AVB key for the
device. This secures it but wouldn't be usable for shipping out-of-band
updates to APEX components across multiple devices. You could switch to
using a single shared APEX APK signing key and AVB signing key. You'll
also need to add parameters for additional device-specific APEX components
not included in our release signing script which was set up based on the
Pixel 6 and Pixel 6 Pro.</p>
<p><strong>If you don't disable updatable APEX packages, you need to generate an APK and <p>Consult the upstream documentation on generating these keys. It will
AVB key for each APEX component and extend the GrapheneOS release.sh script to pass likely be covered here in the future, especially if non-flattened APEX
the appropriate parameters to replace the APK and AVB keys for each APEX components become unavoidable.</p>
component.</strong></p>
<p>APEX components that are not flattened are a signed APK (used to verify updates)
with an embedded filesystem image signed with an AVB key (for verified boot). Each
APEX package must have a unique set of keys. GrapheneOS has no use for these
out-of-band updates at this time and flattening APEX components avoids needing a bunch
of extra keys and complexity.</p>
<p>For now, consult the upstream documentation on generating these keys. It will be
covered here in the future.</p>
</section> </section>
</section> </section>