Full Report
Posted by Liz Prucka, Hamzeh Zawawy, Rishika Hooda, Android Security and Privacy Team Last year, Google's Android Red Team partnered with Arm to conduct an in-depth security analysis of the Mali GPU, a component used in billions of Android devices worldwide. This collaboration was a significant step in proactively identifying and fixing vulnerabilities in the GPU software and firmware stack. While finding and fixing individual bugs is crucial, and progress continues on eliminating them entirely, making them unreachable by restricting attack surface is another effective and often faster way to improve security. This post details our efforts in partnership with Arm to further harden the GPU by reducing the driver's attack surface. The Growing Threat: Why GPU Security Matters The Graphics Processing Unit (GPU) has become a critical and attractive target for attackers due to its complexity and privileged access to the system. The scale of this threat is significant: since 2021, the majority of Android kernel driver-based exploits have targeted the GPU. These exploits primarily target the interface between the User-Mode Driver (UMD) and the highly privileged Kernel-Mode Driver (KMD), where flaws can be exploited by malicious input to trigger memory corruption. Partnership with Arm Our goal is to raise the bar on GPU security, ensuring the Mali GPU driver and firmware remain highly resilient against potential threats. We partnered with Arm to conduct an analysis of the Mali driver, used on approximately 45% of Android devices. This collaboration was crucial for understanding the driver’s attack surface and identifying areas that posed a security risk, but were not necessary for production use. The Right Tool for the Job: Hardening with SELinux One of the key findings of our investigation was the opportunity to restrict access to certain GPU IOCTLs. IOCTLs act as the GPU kernel driver’s user input and output, as well as the attack surface. This approach builds on earlier kernel hardening efforts, such as those described in the 2016 post Protecting Android with More Linux Security. Mali ioctls can be broadly categorized as: Unprivileged: Necessary for normal operation. Instrumentation: Used by developers for profiling and debugging. Restricted: Should not be used by applications in production. This includes IOCTLs which are intended only for GPU development, as well as IOCTLs which have been deprecated and are no longer used by a device’s current User-Mode Driver (UMD) version. Our goal is to block access to deprecated and debug IOCTLs in production. Instrumentation IOCTLs are intended for use by profiling tools to monitor system GPU performance and are not intended to be directly used by applications in production. As such, access is restricted to shell or applications marked as debuggable. Production IOCTLs remain accessible to regular applications. A Staged Rollout The approach is iterative and is a staged rollout for devices using the Mali GPU. This way, we were able to carefully monitor real-world usage and collect data to validate the policy, minimizing the risk of breaking legitimate applications before moving to broader adoption: Opt-In Policy: We started with an "opt-in" policy. We created a new SELinux attribute, gpu_harden, that disallowed instrumentation ioctls. We then selectively applied this attribute to certain system apps to test the impact. We used the allowxperm rule to audit, but not deny, access to the intended resource, and monitored the denial logs to ensure no breakage. Opt-Out Policy: Once we were confident that our approach was sound, we moved to an "opt-out" policy. We created a gpu_debug domain that would allow access to instrumentation ioctls. All applications were hardened by default, but developers could opt-out by: Running on a rooted device. Setting the android:debuggable="true" attribute in their app's manifest. Requesting a permanent exception in the SELinux policy for their application. This approach allowed us to roll out the new security policy broadly while minimizing the impact on developers. Step by Step instructions on how to add your Sepolicy To help our partners and the broader ecosystem adopt similar hardening measures, this section provides a practical, step-by-step guide for implementing a robust SELinux policy to filter GPU ioctls. This example is based on the policy we implemented for the Mali GPU on Android devices. The core principle is to create a flexible, platform-level macro that allows each device to define its own specific lists of GPU ioctl commands to be restricted. This approach separates the general policy logic from the device-specific implementation. Official documentation detailing the added macro and GPU security policy is available at: SELinux Hardening Macro: GPU Syscall Filtering Android Security Change: Android 16 Behavior Changes Step 1: Utilize the Platform-Level Hardening Macro The first step is to use a generic macro that we built in the platform's system/sepolicy that can be used by any device. This macro establishes the framework for filtering different categories of ioctls. In the file/sepolicy/public/te_macros, a new macro is created. This macro allows device-specific policies to supply their own lists of ioctls to be filtered. The macro is designed to: Allow all applications (appdomain) access to a defined list of unprivileged ioctls. Restrict access to sensitive "instrumentation" ioctls, only permitting them for debugging tools like shell or runas_app when the application is debuggable. Block access to privileged ioctls based on the application's target SDK version, maintaining compatibility for older applications. Step 2: Define Device-Specific IOCTL Lists With the platform macro in place, you can now create a device-specific implementation. This involves defining the exact ioctl commands used by your particular GPU driver. Create an ioctl_macros file in your device's sepolicy directory (e.g., device/your_company/your_device/sepolicy/ioctl_macros). Define the ioctl lists inside this file, categorizing them as needed. Based on our analysis, we recommend at least mali_production_ioctls, mali_instrumentation_ioctls, and mali_debug_ioctls. These lists will contain the hexadecimal ioctl numbers specific to your driver. For example, you can define your IOCTL lists as follows: define(`unpriv_gpu_ioctls', `0x0000, 0x0001, 0x0002') define(`restricted_ioctls', `0x1110, 0x1111, 0x1112') define(`instrumentation_gpu_ioctls', `0x2220, 0x2221, 0x2222') Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases. Step 3: Apply the Policy to the GPU Device Now, you apply the policy to the GPU device node using the macro you created. Create a gpu.te file in your device's sepolicy directory. Call the platform macro from within this file, passing in the device label and the ioctl lists you just defined. Step 4: Test, Refine, and Enforce As with any SELinux policy development, the process should be iterative. This iterative process is consistent with best practices for SELinux policy development outlined in the Android Open Source Project documentation. Conclusion Attack surface reduction is an effective approach to security hardening, rendering vulnerabilities unreachable. This technique is particularly effective because it provides users strong protection against existing but also not-yet-discovered vulnerabilities, and vulnerabilities that might be introduced in the future. This effort spans across Android and Android OEMs, and required close collaboration with Arm. The Android security team is committed to collaborating with ecosystem partners to drive broader adoption of this approach to help harden the GPU. Acknowledgments Thank you to Jeffrey Vander Stoep for his valuable suggestions and extensive feedback on this post.
Analysis Summary
# Best Practices: Hardening GPU Security via Attack Surface Reduction (SELinux)
## Overview
These recommendations focus on proactively improving system security, particularly for devices utilizing Graphics Processing Units (GPUs) like the Mali GPU, by drastically restricting the kernel driver's attack surface. This is achieved by enforcing fine-grained access controls on **IOCTLs (Input/Output Control)** using SELinux policies to block access to deprecated, development-only, and debugging functionality from production applications.
## Key Recommendations
### Immediate Actions
1. **Identify and Categorize GPU IOCTLs:** Immediately inventory all GPU driver IOCTLs and categorize them based on necessity for production workloads (Unprivileged, Instrumentation, Restricted/Debug).
2. **Audit Access to Restricted IOCTLs:** Deploy an **opt-in** SELinux policy utilizing the `allowxperm` rule (auditing without denying) for instrumentation IOCTLs to monitor real-world denials without immediately breaking functionality.
3. **Confirm Production IOCTL Needs:** Verify which unprivileged IOCTLs are absolutely necessary for standard, non-debug applications to operate correctly.
### Short-term Improvements (1-3 months)
1. **Implement Staged Rollout Strategy:** Transition from the auditing phase to a denial phase using a staged, iterative rollout (starting with internal testing or sensitive systems) based on the collected denial logs.
2. **Enforce Instrumentation IOCTL Restriction:** Implement SELinux policies to restrict access to **Instrumentation IOCTLs**, allowing them only for processes running as `shell` or applications explicitly marked as `debuggable="true"`.
3. **Block Deprecated IOCTLs:** Immediately block production applications from accessing any IOCTLs identified as deprecated, as these pose unnecessary residual risk.
### Long-term Strategy (3+ months)
1. **Adopt Full Opt-Out Policy:** Harden the default SELinux policy so that access to restricted/instrumentation IOCTLs is denied for all non-debug applications, requiring developers to explicitly opt-out (e.g., by setting `android:debuggable="true"`).
2. **Establish Platform-Level Hardening Macro:** For ecosystem partners, integrate and utilize the provided platform-level SELinux hardening macro (e.g., in `system/sepolicy/public/te_macros`) to create a standardized, reusable filtering framework.
3. **Continuous IOCTL List Maintenance:** Integrate the classification of new or updated GPU IOCTLs into the regular driver update and platform release process, ensuring the device-specific IOCTL lists are kept current with vendor documentation (e.g., Arm's `Documentation/ioctl-categories.rst`).
## Implementation Guidance
The core implementation strategy revolves around defining device-specific IOCTL lists and applying them via a standardized platform-level SELinux macro.
### For Small Organizations
1. **Focus on Vendor Documentation:** Prioritize obtaining and utilizing the vendor's official categorization of IOCTLs (e.g., Arm's documentation) to define initial device-specific lists accurately.
2. **Audit First:** Implement the audit-only (`allowxperm` used for monitoring) "opt-in" approach first, as this allows for rapid identification of functional breakage without immediate security enforcement, which is crucial when dedicated testing resources might be limited.
3. **Adopt Default Policy:** Once testing shows stability, apply the hardened configuration broadly to all production builds, ensuring no application defaults to accidental debug/instrumentation access.
### For Medium Organizations
1. **Automate List Generation (If Possible):** If multiple devices/SKUs are managed, develop scripts to automatically populate the device-specific IOCTL lists (`ioctl_macros` files) based on the platform macro structure.
2. **Formal Exception Process:** Establish a formal review process for any application that requires an exemption from the hardened policy (i.e., requesting permanent SELinux policy exceptions or requiring `android:debuggable="true"` in production).
3. **Utilize GPU Debug Domain:** Implement the designated `gpu_debug` domain to clearly separate debugging tools/environments from standard production environments.
### For Large Enterprises
1. **Develop Custom Platform Macro:** If not using Android AOSP directly, create a proprietary, device-specific hardening macro structure that mirrors the platform logic provided, ensuring separation between policy logic and implementation details.
2. **Integrate into CI/CD:** Embed the SELinux policy validation steps, including checking for any newly introduced restricted IOCTLs in driver updates, directly into the Continuous Integration/Continuous Deployment pipeline.
3. **Targeted Policy Enforcement:** Leverage the staged rollout capability to deploy new denial policies incrementally across device fleets based on age, risk profile, or user segment to mitigate broad impact from unforeseen compatibility issues.
## Configuration Examples
**Policy Structure Principle:** Based on the provided guide, implementation requires four layers:
1. **Platform Macro (`te_macros`):** Contains the generic logic to filter IOCTLs based on predefined categories (Unprivileged, Instrumentation, Restricted).
2. **Device-Specific IOCTL Definition (`ioctl_macros` in `device/your_company/your_device/sepolicy/`):** Defines the actual hexadecimal numbers for each category for the specific GPU implementation.
* Example definitions required:
* `define(`unpriv_gpu_ioctls', '0xAAA, 0xBBB')`
* `define(`instrumentation_gpu_ioctls', '0xCCC, 0xDDD')`
* `define(`restricted_ioctls', '0xEEE, 0xFFF')`
3. **Device Policy Application (`gpu.te` in device sepolicy):** Calls the platform macro, passing the device label and the defined IOCTL lists.
4. **Domain Hardening:**
* **To Block Access (Hardened State):** Ensure production domains do not have access to the `gpu_debug` domain's permissions.
* **To Allow Debug Access (Opt-Out):** Ensure debuggable apps or shell processes are correctly placed in a domain that has explicit permission to use instrumentation IOCTLs (e.g., via SELinux policies permitting access to `instrumentation_gpu_ioctls` only when debuggable).
## Compliance Alignment
* **NIST SP 800-53 (AC-3: Access Enforcement):** Directly supports enforcing strict access controls based on security categorization, specifically by limiting system interface access (IOCTLs).
* **CIS Controls (Control 4: Secure Configuration of Hard-ware, Software, and Firmware):** This process systematically hardens the kernel/driver configuration by disabling unnecessary interfaces exposed to user space.
* **ISO/IEC 27002 (A.9.2.3: Management of privileged access rights):** By restricting privileged interface access (Kernel Mode Driver interaction via KMD/UMD boundary) based on the application's purpose (production vs. debug), organizations are implementing robust access management.
## Common Pitfalls to Avoid
* **Skipping the Audit Phase:** Moving directly to denial policies without an auditing phase can lead to unexpected application crashes in production when necessary, but yet-to-be-classified, IOCTLs are suddenly blocked.
* **Incomplete IOCTL Listing:** Failing to find all active, restricted IOCTLs in the driver and only blocking a subset leaves residual attack surface open. Always rely on vendor documentation for definitive lists.
* **Broad Debuggable Flags:** Developers should **not** set `android:debuggable="true"` in production manifests simply to bypass security restrictions. This signals a need for process separation (the `gpu_debug` domain) rather than policy relaxation.
## Resources
* Official Documentation detailing the added macro and GPU security policy: SELinux Hardening Macro: GPU Syscall Filtering (As referenced in the article).
* Prior hardening context: [Protecting Android with More Linux Security](https://security.googleblog.com/2016/07/protecting-android-with-more-linux.html) (For background on SELinux utilization in Android).
* Vendor Specifics: Documentation/ioctl-categories.rst within the vendor GPU driver release (e.g., Arm r54p2 release).