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

update info on porting

Browse Source
This commit is contained in:
Daniel Micay 2024-07-31 21:05:51 -04:00
parent b1fe991fd3
commit 6c25b49460
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
static/build.html
View File

@ -176,15 +176,18 @@
<p><strong>We recommend using the sdk_phone64_x86_64 target in either the <p><strong>We recommend using the sdk_phone64_x86_64 target in either the
userdebug or eng variant for most development work.</strong></p> userdebug or eng variant for most development work.</strong></p>
<p>Providing proper support for a device or generic device family requires providing <p>Providing proper support for a device or generic device family requires
an up-to-date kernel and device support code including driver libraries, firmware and providing an up-to-date kernel and device support code including driver
device SELinux policy extensions. Other than some special cases like the emulator, the libraries, firmware and device SELinux policy extensions. Other than some
generic targets rely on the device support code present on the device. Shipping all of special cases like the emulator, the generic targets rely on the device support
this is necessary for full security updates and is tied to enabling verified boot / code present on the device. Shipping all of this is necessary for full security
attestation. Pixel targets have a lot of device-specific hardening in the AOSP base updates and is tied to enabling verified boot / attestation. Device-specific
along with some in GrapheneOS which needs to be ported over too. For example, various driver changes are required to support GrapheneOS features such as the
security features in the kernel including type-based Control Flow Integrity (CFI) and hardware-level USB-C port control. There's also a lot of device-specific work to
the shadow call stack are currently specific to the kernels for these devices.</p> work around or resolve memory corruption bugs uncovered by our features. Most
devices are also missing a lot of standard hardware-based security features we
use such as hardware memory taggings so those features will inherently not be
possible to port to a device not capable of it.</p>
</section> </section>
<section id="build-dependencies"> <section id="build-dependencies">