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

generic targets aren't supported

Browse Source
This commit is contained in:
Daniel Micay 2023-12-08 12:27:23 -05:00
parent 7cb9b4c498
commit f5e449bb79
2 changed files with 15 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
static/build.html
View File

@ -178,20 +178,6 @@
<p><strong>We recommend using the sdk_phone_x86_64 target in either the
userdebug or eng variant for most development work.</strong></p>
<p>Generic targets:</p>
<ul>
<li>aosp_arm</li>
<li>aosp_arm64</li>
<li>aosp_x86</li>
<li>aosp_x86_64</li>
</ul>
<p>These generic targets can be used with the emulator along with many smartphones,
tablets and other devices. These targets don't receive full monthly security updates,
don't offer all of the baseline security features and are intended for development
usage.</p>
<p>Providing proper support for a device or generic device family requires providing
an up-to-date kernel and device support code including driver libraries, firmware and
device SELinux policy extensions. Other than some special cases like the emulator, the

27
static/faq.html
View File

@ -171,18 +171,21 @@
the same standards. For most devices, the hardware and firmware will prevent providing
a reasonably secure device, regardless of the work put into device support.</p>
<p>GrapheneOS also supports generic targets, but these aren't suitable for production
usage and are only intended for development and testing use. For mobile devices, the
generic targets simply run on top of the underlying device support code (firmware,
kernel, device trees, vendor code) rather than shipping it and keeping it updated. It
would be possible to ship generic system images with separate updates for the device
support code. However, it would be drastically more complicated to maintain and
support due to combinations of different versions and it would cause complications for
the hardening done by GrapheneOS. The motivation doesn't exist for GrapheneOS, since
full updates with deltas to minimize bandwidth can be shipped for every device and
GrapheneOS is the only party involved in providing the updates. For the same reason,
it has little use for the ability to provide out-of-band updates to system image
components including all the apps and many other components.</p>
<p>GrapheneOS does not support being used as a Generic System Image, which
only exists for development/testing purposes and isn't usable for GrapheneOS
since we require kernel changes and the userspace part of the OS cannot run on
top of a kernel without the required functionality. The generic targets simply
run on top of the underlying device support code (firmware, kernel, device
trees, vendor code) rather than shipping it and keeping it updated. It would
be possible to ship generic system images with separate updates for the device
support code. However, it would be drastically more complicated to maintain
and support due to combinations of different versions and it would cause
complications for the hardening done by GrapheneOS. The motivation doesn't
exist for GrapheneOS, since full updates with deltas to minimize bandwidth can
be shipped for every device and GrapheneOS is the only party involved in
providing the updates. For the same reason, it has little use for the ability
to provide out-of-band updates to system image components including all the
apps and many other components.</p>
<p>Some of the GrapheneOS sub-projects support other operating systems on a broader
range of devices. Device support for Auditor and AttestationServer is documented in