Google On-line Safety Weblog: Additional Hardening Android GPUs

Final yr, Google’s Android Pink Workforce partnered with Arm to conduct an in-depth safety evaluation of the Mali GPU, a element utilized in billions of Android units worldwide. This collaboration was a big step in proactively figuring out and fixing vulnerabilities within the GPU software program and firmware stack.

Whereas discovering and fixing particular person bugs is essential, and progress continues on eliminating them solely, making them unreachable by proscribing assault floor is one other efficient and infrequently quicker method to enhance safety. This submit particulars our efforts in partnership with Arm to additional harden the GPU by decreasing the driving force’s assault floor.

The Rising Menace: Why GPU Safety Issues

The Graphics Processing Unit (GPU) has change into a essential and enticing goal for attackers on account of its complexity and privileged entry to the system. The dimensions of this menace is critical: since 2021, the vast majority of Android kernel driver-based exploits have focused the GPU. These exploits primarily goal the interface between the Person-Mode Driver (UMD) and the extremely privileged Kernel-Mode Driver (KMD), the place flaws may be exploited by malicious enter to set off reminiscence corruption.

Partnership with Arm

Our aim is to boost the bar on GPU safety, guaranteeing the Mali GPU driver and firmware stay extremely resilient towards potential threats. We partnered with Arm to conduct an evaluation of the Mali driver, used on roughly 45% of Android units. This collaboration was essential for understanding the driving force’s assault floor and figuring out areas that posed a safety threat, however weren’t needed for manufacturing use.

The Proper Device for the Job: Hardening with SELinux

One of many key findings of our investigation was the chance to limit entry to sure GPU IOCTLs. IOCTLs act because the GPU kernel driver’s consumer enter and output, in addition to the assault floor. This strategy builds on earlier kernel hardening efforts, similar to these described within the 2016 submit Defending Android with Extra Linux Safety. Mali ioctls may be broadly categorized as:

• Unprivileged: Mandatory for regular operation.
• Instrumentation: Utilized by builders for profiling and debugging.
• Restricted: Shouldn’t be utilized by functions in manufacturing. This consists of IOCTLs that are meant just for GPU growth, in addition to IOCTLs which have been deprecated and are now not utilized by a tool’s present Person-Mode Driver (UMD) model.

Our aim is to dam entry to deprecated and debug IOCTLs in manufacturing. Instrumentation IOCTLs are meant to be used by profiling instruments to watch system GPU efficiency and aren’t meant to be instantly utilized by functions in manufacturing. As such, entry is restricted to shell or functions marked as debuggable. Manufacturing IOCTLs stay accessible to common functions.

A Staged Rollout

The strategy is iterative and is a staged rollout for units utilizing the Mali GPU. This fashion, we have been capable of fastidiously monitor real-world utilization and gather information to validate the coverage, minimizing the danger of breaking legit functions earlier than shifting to broader adoption:

1. Choose-In Coverage: We began with an “opt-in” coverage. We created a brand new SELinux attribute, gpu_harden, that disallowed instrumentation ioctls. We then selectively utilized this attribute to sure system apps to check the influence. We used the allowxperm rule to audit, however not deny, entry to the meant useful resource, and monitored the denial logs to make sure no breakage.
2. Choose-Out Coverage: As soon as we have been assured that our strategy was sound, we moved to an “opt-out” coverage. We created a gpu_debug area that will enable entry to instrumentation ioctls. All functions have been hardened by default, however builders might opt-out by:

• Working on a rooted machine.
• Setting the android:debuggable="true" attribute of their app’s manifest.
• Requesting a everlasting exception within the SELinux coverage for his or her utility.

This strategy allowed us to roll out the brand new safety coverage broadly whereas minimizing the influence on builders.

Step by Step directions on methods to add your Sepolicy

To assist our companions and the broader ecosystem undertake comparable hardening measures, this part supplies a sensible, step-by-step information for implementing a strong SELinux coverage to filter GPU ioctls. This instance relies on the coverage we applied for the Mali GPU on Android units.

The core precept is to create a versatile, platform-level macro that enables every machine to outline its personal particular lists of GPU ioctl instructions to be restricted. This strategy separates the final coverage logic from the device-specific implementation.

Official documentation detailing the added macro and GPU safety coverage is out there at:

SELinux Hardening Macro: GPU Syscall Filtering

Android Safety Change: Android 16 Habits Modifications

Step 1: Make the most of the Platform-Degree Hardening Macro

Step one is to make use of a generic macro that we constructed within the platform’s system/sepolicy that can be utilized by any machine. This macro establishes the framework for filtering totally different classes of ioctls.

Within the file/sepolicy/public/te_macros, a brand new macro is created. This macro permits device-specific insurance policies to provide their very own lists of ioctls to be filtered. The macro is designed to:

• Permit all functions (appdomain) entry to an outlined record of unprivileged ioctls.
• Prohibit entry to delicate “instrumentation” ioctls, solely allowing them for debugging instruments like shell or runas_app when the applying is debuggable.
• Block entry to privileged ioctls based mostly on the applying’s goal SDK model, sustaining compatibility for older functions.

Step 2: Outline Machine-Particular IOCTL Lists

With the platform macro in place, now you can create a device-specific implementation. This includes defining the precise ioctl instructions utilized by your specific GPU driver.

1. Create an ioctl_macros file in your machine’s sepolicy listing (e.g., machine/your_company/your_device/sepolicy/ioctl_macros).
2. Outline the ioctl lists inside this file, categorizing them as wanted. Based mostly on our evaluation, we advocate a minimum of mali_production_ioctls, mali_instrumentation_ioctls, and mali_debug_ioctls. These lists will include the hexadecimal ioctl numbers particular to your driver.

   For instance, you may outline your IOCTL lists as follows:

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

Arm has supplied official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 launch. This record will proceed to be maintained in future driver releases.

Step 3: Apply the Coverage to the GPU Machine

Now, you apply the coverage to the GPU machine node utilizing the macro you created.

1. Create a gpu.te file in your machine’s sepolicy listing.
2. Name the platform macro from inside this file, passing within the machine label and the ioctl lists you simply outlined.

Step 4: Take a look at, Refine, and Implement

As with every SELinux coverage growth, the method must be iterative. This iterative course of is according to finest practices for SELinux coverage growth outlined within the Android Open Supply Venture documentation.

Conclusion

Assault floor discount is an efficient strategy to safety hardening, rendering vulnerabilities unreachable. This method is especially efficient as a result of it supplies customers robust safety towards current but in addition not-yet-discovered vulnerabilities, and vulnerabilities that is likely to be launched sooner or later. This effort spans throughout Android and Android OEMs, and required shut collaboration with Arm. The Android safety group is dedicated to collaborating with ecosystem companions to drive broader adoption of this strategy to assist harden the GPU.

Acknowledgments

Thanks to Jeffrey Vander Stoep for his invaluable options and intensive suggestions on this submit.