

From the grapheneos faq section on device support, which details the kinds of hardware and firmware security features required and present on pixels (but may be missing on other devices):
Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.
Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:
- Support for using alternate operating systems including full hardware security functionality
- Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
- At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
- Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)
- Linux 6.1, 6.6 or 6.12 Generic Kernel Image (GKI) support
- Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
- Hardware memory tagging (ARM MTE or equivalent)
- Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn’t used or can’t be deployed (BTI/PAC, CET IBT or equivalent)
- PXN, SMEP or equivalent
- PAN, SMAP or equivalent
- Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode and decode, image processor and other components
- Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
- Verified boot with rollback protection for firmware
- Verified boot with rollback protection for the OS (Android Verified Boot)
- Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
- StrongBox keystore provided by secure element
- Hardware key attestation support for the StrongBox keystore
- Attest key support for hardware key attestation to provide pinning support
- Weaver disk encryption key derivation throttling provided by secure element
- Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
- Inline disk encryption acceleration with wrapped key support
- 64-bit-only device support code
- Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
- Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
- Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that’s completed
- Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked








Where Should We Begin? is a podcast by the psychotherapist Esther Perel, where each episode is a full couple’s therapy session with an anonymous couple. It’s nice, and sounds like a match for your question.