Android GPU Security Hardening: Reducing Attack Surface with SELinux

Android GPU Security Hardening: A Collaborative Effort to Reduce Attack Surface

Google’s Android Security and Privacy Team, in partnership with Arm, has implemented new security hardening measures for the Mali GPU, a component used in billions of Android devices worldwide. The initiative aims to reduce the GPU driver’s attack surface by restricting access to high-risk IOCTLs (Input/Output Controls) using SELinux (Security-Enhanced Linux) policies.

Why GPU Security Matters

GPUs have become a prime target for attackers due to their complexity and privileged system access. Since 2021, the majority of Android kernel driver-based exploits have targeted GPUs, particularly the interface between the User-Mode Driver (UMD) and the Kernel-Mode Driver (KMD). Malicious input can exploit flaws in this interface, leading to memory corruption and system compromise.

Technical Approach: Restricting GPU IOCTLs with SELinux

The Android Red Team and Arm categorized Mali GPU IOCTLs into three groups:

• Unprivileged IOCTLs – Required for normal operation, accessible to all applications.
• Instrumentation IOCTLs – Used for debugging and profiling, restricted to shell or debuggable applications.
• Restricted IOCTLs – Deprecated or development-only, blocked in production environments.

To enforce these restrictions, Google implemented a staged SELinux policy rollout to minimize disruption:

1. Opt-In Policy – Initially tested on select system apps using a new gpu_harden SELinux attribute.
2. Opt-Out Policy – Applied hardening by default, allowing developers to bypass restrictions via:
   • Rooted devices
   • android:debuggable="true" in the app manifest
   • Permanent SELinux policy exceptions

Implementation Guide for OEMs and Developers

Google has provided a step-by-step guide for partners to adopt similar hardening measures:

1. Utilize the Platform-Level Hardening Macro

A new macro in system/sepolicy/public/te_macros allows device-specific IOCTL filtering:

• Permits unprivileged IOCTLs for all applications (appdomain).
• Restricts instrumentation IOCTLs to debugging tools (shell, runas_app).
• Blocks deprecated IOCTLs based on target SDK version.

2. Define Device-Specific IOCTL Lists

OEMs must create an ioctl_macros file in their device’s SELinux policy directory, categorizing IOCTLs (e.g., mali_production_ioctls, mali_instrumentation_ioctls).

Example:

define(`unpriv_gpu_ioctls', `0x0000, 0x0001, 0x0002')
define(`restricted_ioctls', `0x1110, 0x1111, 0x1112')
define(`instrumentation_gpu_ioctls', `0x2220, 0x2221, 0x2222')

Arm’s official IOCTL categorization is available in their r54p2 GPU documentation.

3. Apply the Policy to the GPU Device

Create a gpu.te file in the device’s SELinux policy directory and invoke the platform macro with the defined IOCTL lists.

4. Test, Refine, and Enforce

Follow iterative SELinux policy development best practices, auditing denial logs to ensure no legitimate applications are disrupted.

Impact and Future Outlook

This hardening effort reduces the attack surface of Mali GPUs, protecting users from both known and unknown vulnerabilities. By making vulnerabilities unreachable, the approach provides long-term security benefits. Google encourages OEMs to adopt these measures, reinforcing GPU security across the Android ecosystem.

Official Documentation

• SELinux Hardening Macro: GPU Syscall Filtering
• Android 16 Behavior Changes: GPU Syscall Filtering

Acknowledgments

Special thanks to Jeffrey Vander Stoep for contributions to this initiative.