• Development

  • Consideration of OnePlus 12 or alternative devices in general

Hi, please don't bring out the "It's not a Pixel" pitchfork yet.

I'm starting a discussion to potentially consider a device from an alternative vendor. Unfortunately, the dire state of custom OS development on Android leaves only OnePlus as a major vendor besides Google that has a implementation of Android Verified Boot with support for avb_custom_key, and thus potential first-class support for custom OSs. (Samsung and Motorola blow eFuses at the thought of unlocking bootloaders...)

Having support for an alternate vendor, or at least some research towards it, while not a goal for GrapheneOS, would also help the broader community on the security of the devices being considered. I know this is a Chinese vendor. Part of the research I am thinking would be if the harm may be mitigated by minimizing the use of vendor blobs at the cost of reduced feature parity with the stock OS.

I'm sharing some of my findings on whether the device can possibly meet the requirements to start a discussion and see if there is at all any interest from the project and the community. If this passes the smell test and there is interest, I am willing to fund a test device and/or some time of a developer for a more detailed assessment.

I rearranged the requirements from the FAQ a little based on big themes.

Android Verified Boot / OS Support

  • Support for using alternate operating systems including full hardware security functionality
  • 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)

Very likely. Tested that avb_custom_key can be provisioned. To be tested, but board support isn't there yet so I can't build to test.

Vendor updates, ASB patching

  • Complete monthly Android Security Bulletin patches without any regular delays longer than a week

Maybe? Questionable support globally, but certain regions get ASB patched earlier than others. To be observed.

  • At least 5 years of updates from launch for phones (Pixels now have 7) and 7 years for tablets

Yes. Vendor pledges 5 years of security updates and 4 major updates.

  • Vendor 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)

Maybe. With QPR2 starting the trend of quarterly releases being bundled with ASBs, it is more likely.

  • Linux 5.15 or Linux 6.1 Generic Kernel Image (GKI) support

Likely. Device launched with 6.1 (https://github.com/OnePlusOSS/android_kernel_oneplus_sm8650). To verify GKI.

Architectural features

  • 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)
  • BTI/PAC, CET or equivalent
  • PXN, SMEP or equivalent
  • PAN, SMAP or equivalent

Depends on what 8Gen3 supports and what is exposed. I know Qualcomm messes with ELs for virtualization, so maybe not.

  • 64-bit-only device support code

Very likely, as SD 8Gen3 is 64-bit only.

TEE

  • 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

OnePlus press releases claim "Strong Box4powered by Built-in eSE (embedded Secure Element)" via their "Device Security Engine 3.0, which is based on the Trusted Execution Environment (TEE)". How much is exposed to custom OSs is unknown.

Grab bag - no idea about those

  • Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components
  • 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
  • de0u replied to this.

    Hey, that's not a Pixel! (just kidding).

    Thanks for taking the time to write this post.

    If you're looking for a quick and easy reason "why not" for this device, Snapdragon currently doesn't support MTE, which disqualifies current Snapdragon devices. They will likely support it in 2025/2026, though.

    If I look into it, I'm sure to find more issues, including with the most basic things such as timely updates. A commitment to X years of updates doesn't mean much if said updates are routinely delayed. Without looking into it, I believe OnePlus devices didn't get Android 14 until at least a couple of months after its release. We had our release ready 3 days after. If we were to support this device, we wouldn't be able to move in that time, missing critical security fixes in the process.

    Also, it's not just about what the device starts with, but especially now that devices are trending towards longer support (around 5 years and in the case of current Pixels, 7 years), it is important to evaluate how receptive the OEM is to reports. We routinely report issues to Google, including issues in the firmware which we cannot address downstream. They do respond to those and implement them. An example is
    the reset attack mitigation improvements for firmware we requested to address physical extraction attack vectors being exploited by forensics companies in the wild. They are shipping those in April for Pixels. Once that happens, it'll be a requirement for new devices going forward. Security is a moving target, and a lot of factors go into deciding what to support, including factors that come into play after a device's initial release.

      doodle OnePlus press releases claim "Strong Box4 powered by Built-in eSE (embedded Secure Element)" via their "Device Security Engine 3.0, which is based on the Trusted Execution Environment (TEE)". How much is exposed to custom OSs is unknown.

      It's not clear what they mean by "StrongBox4". I looked quickly and did not see anything. Key-derivation throttling is pretty important, for example, also insider-attack resistance. If it isn't possible to get clear documentation on the "StrongBox4" feature set, personally I would not assume the right features will be there. Google has top security people and they have put in a lot of work on Pixel hardware security.

      Is information available on the "StrongBox4" feature set?

          matchboxbananasynergy

          Thank you for the reply. It's discouraging to hear that Snapdragons still don't get MTE. I remember back in 8G1 it was supposed to get it then as an extension to ARMv8 but then I couldn't find further info on this. So it looks like the long answer is still, there really is only Pixel :-)

          I still kind of feel sad for the rest of the Android ecosystem, though, in terms of updates, etc.

          If I look into it, I'm sure to find more issues, including with the most basic things such as timely updates.

          OnePlus seems to be, at least for flagships, to be supporting their devices in a timely manner. I looked at the release dates of last year's OnePlus 11 flagship and it seemed not too bad:

          • Feb 2024 ASB: released Feb 20 globally
          • Jan 2024 ASB: released Jan 15 globally
          • Dec 2023 ASB: released Dec 15 globally
          • Nov 2023 ASB / Android 14: released Nov 16 globally, so 1 month late
            ...

          We had our release ready 3 days after. If we were to support this device, we wouldn't be able to move in that time, missing critical security fixes in the process.

          This brings me to another question. Assuming a vendor can provide timely Android and firmware updates for their device:

          • how much of a difficulty is it for GrapheneOS to support a device that is not close to stock AOSP like Pixels are?
          • how much of the work GrapheneOS does for updates is dependent on the vendor releasing sources for the corresponding monthly release vs. just having "some kind of Android that patches the monthly ASB" for firmware/blobs to be extracted? I imagine GPL source releases will be much harder to get timely for third-party vendors.

          it is important to evaluate how receptive the OEM is to reports.

          That is a great point about security being a moving target. No idea about OnePlus. Huawei seemed to go out of their way to patch exploits (this comes to mind: https://labs.taszk.io/articles/post/huawei_kirin990_bootrom_patch/).

          I know people already scream at GrapheneOS requiring a Google device, imagine supporting a device from a Chinese vendor. I don't really want to discount Chinese vendors - Huawei has an interesting TEE implementation (https://blog.impalabs.com/2212_huawei-security-hypervisor.html) and it looks like they put thought into security as well. Again, no idea what OnePlus/Oppo does in terms of this.

          Another question if you don't mind. Ignoring the possibility of vendors being actively hostile, GrapheneOS's attack surface mitigation would really do well to mitigate potential sloppiness and security flaws in the vendor firmware and that is something not provided by any OS on third party devices.
          Can GrapheneOS feasibly play a role in this? I can't imagine myself running the stock OS on a Chinese device for obvious reasons, but alternatives don't provide much in terms of security.

            de0u Good question, there appears to be no public documentation on this other than PR speak, but the use of StrongBox / TEE nomenclature is very deliberate, so I hope there is some functionality that can be reverse engineered for use by a custom OS like GOS.

            Does Pixel publish documentation for the Titan M chips or how to leverage the TEE, or are they standard Android APIs, or are these reverse engineered by GOS? I'm sure OnePlus will never publish documentation on hardware security so my hope is that it can either be reverse engineered for use by GOS or exposed through standard Android APIs.

            • de0u replied to this.

                doodle Does Pixel publish documentation for the Titan M chips or how to leverage the TEE, or are they standard Android APIs, or are these reverse engineered by GOS?

                Google publishes AOSP source code for in-support Pixel devices, meaning that anybody can download the AOSP sources, and build a working albeit minimal OS -- kernel and user space. A quick glance suggests OnePlus publishes only the source code they are required to based on the kernel being GPL'd; I did not see any user-space source code. That said, it appears that DivestOS supports some OnePlus devices, though the security features available are unclear to me.

                doodle I'm sure OnePlus will never publish documentation on hardware security so my hope is that it can either be reverse engineered for use by GOS or exposed through standard Android APIs.

                It might be interesting to look into which hardware-security features are used successfully by DivestOS on OnePlus devices. Meanwhile, I am skeptical that in the near term the GrapheneOS developers will devote the presumably-substantial resources it would take to reverse-engineer devices that a platform vendor wishes to keep closed.