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

remove leftover info on legacy verified boot

Browse Source
This commit is contained in:
Daniel Micay 2019-04-27 09:25:25 -04:00
parent d870d1a383
commit 32696d62ff
1 changed files with 32 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
static/build.html
View File

@ -210,17 +210,17 @@ mv vendor/android-prepare-vendor/DEVICE/BUILD_ID/vendor/google_devices/* vendor/
<h2>Generating release signing keys</h2> <h2>Generating release signing keys</h2>
<p>Keys need to be generated for resigning completed builds from the publicly available test keys. <p>Keys need to be generated for resigning completed builds from the publicly
The keys must then be reused for subsequent builds and cannot be changed without flashing the available test keys. The keys must then be reused for subsequent builds and cannot be
generated factory images again which will perform a factory reset. Note that the keys are used for changed without flashing the generated factory images again which will perform a
a lot more than simply verifying updates and verified boot. Keys must be generated before building factory reset. Note that the keys are used for a lot more than simply verifying
for the Pixel and Pixel XL due to needing to provide the keys to the kernel build system, but this updates and verified boot.</p>
step can be done after building for Nexus devices.</p>
<p>The keys should not be given passwords due to limitations in the upstream scripts. If you want to <p>The keys should not be given passwords due to limitations in the upstream scripts.
secure them at rest, you should take a different approach where they can still be available to the If you want to secure them at rest, you should take a different approach where they
signing scripts as a directory of unencrypted keys. The sample certificate subject can be replaced can still be available to the signing scripts as a directory of unencrypted keys. The
with your own information or simply left as-is.</p> sample certificate subject can be replaced with your own information or simply left
as-is.</p>
<p>To generate keys for crosshatch (you should use unique keys per device <p>To generate keys for crosshatch (you should use unique keys per device
variant):</p> variant):</p>
@ -240,36 +240,39 @@ cd ../..</pre>
<h2>Building</h2> <h2>Building</h2>
<p>Incremental builds (i.e. starting from the old build) usually work for development and are the <p>Incremental builds (i.e. starting from the old build) usually work for development
normal way to develop changes. However, there are cases where changes are not properly picked up and are the normal way to develop changes. However, there are cases where changes are
by the build system. For production builds, you should remove the remnants of any past builds not properly picked up by the build system. For production builds, you should remove
before starting, particularly if there were non-trivial changes:</p> the remnants of any past builds before starting, particularly if there were
non-trivial changes:</p>
<pre>rm -r out</pre> <pre>rm -r out</pre>
<p>Start the build process, with -j# used to set the number of parallel jobs to the number of CPU <p>Start the build process, with -j# used to set the number of parallel jobs to the
threads. You also need 2-4GiB of memory per job, so reduce it based on available memory if number of CPU threads. You also need 2-4GiB of memory per job, so reduce it based on
necessary:</p> available memory if necessary:</p>
<pre>make target-files-package -j20</pre> <pre>make target-files-package -j20</pre>
<h2>Faster builds for development use only</h2> <h2>Faster builds for development use only</h2>
<p>The normal production build process involves building a target files package to be resigned with <p>The normal production build process involves building a target files package to be
secure release keys and then converted into factory images and/or an update zip via the sections resigned with secure release keys and then converted into factory images and/or an
below. If you have a dedicated development device with no security requirements, you can save time update zip via the sections below. If you have a dedicated development device with no
by using the default make target, leaving the bootloader unlocked and flashing the raw images that security requirements, you can save time by using the default make target, leaving the
are signed with the default public test keys:</p> bootloader unlocked and flashing the raw images that are signed with the default
public test keys:</p>
<pre>make -j20</pre> <pre>make -j20</pre>
<p>Technically, you could generate test key signed update packages. However, there's no point of <p>Technically, you could generate test key signed update packages. However, there's
sideloading update packages when the bootloader is unlocked and there's no value in a locked no point of sideloading update packages when the bootloader is unlocked and there's no
bootloader without signing the build using release keys, since verified boot will be meaningless value in a locked bootloader without signing the build using release keys, since
and the keys used to verify sideloaded updates are also public. The only reason to use update verified boot will be meaningless and the keys used to verify sideloaded updates are
packages or a locked bootloader without signing the build with release keys would be testing that also public. The only reason to use update packages or a locked bootloader without
functionality and it makes a lot more sense to test it with proper signing keys rather than the signing the build with release keys would be testing that functionality and it makes a
default public test keys.</p> lot more sense to test it with proper signing keys rather than the default public test
keys.</p>
<h2>Generating signed factory images and full update packages</h2> <h2>Generating signed factory images and full update packages</h2>