As I've mentioned before, Android uses Clang's forward-edge Control Flow Integrity (CFI) for the Linux kernel on the Pixel 3 to protect indirect calls from control flow hijacking:
android-developers.googleblog.com/2018/10/contro
This includes support for cross-DSO CFI to support dynamic kernel modules.
Conversation
Clang CFI heavily depends on LTO for decent performance and to improve precision beyond types, while also avoiding fundamentally changing the ABI for calls. Cross-DSO (cross-library) CFI is supported but is less efficient and less complete information leads to less precision.
1
2
Android has full support for cross-DSO CFI in userspace and the kernel, including a substantially better userspace implementation than the portable one: struct.github.io/cross_dso_cfi.. This allows the Pixel 3 to support dynamic kernel modules, but it only uses them statically anyway.
1
6
As part of the initial work on Pixel 3 hardening for GrapheneOS, I've migrated to using only static kernel modules. Either way the modules are verified (by both dm-verity and module signing, redundantly), but building them in does reduce attack surface and makes CFI more precise.
1
2
Clang does't yet have backward-edge CFI (clang.llvm.org/docs/ControlFl) to protect return addresses, but Android Q brings Shadow Call Stack support to the kernel (clang.llvm.org/docs/ShadowCal), after the failed attempt at using SafeStack in the kernel for Android P:
android.googlesource.com/kernel/msm/+/f
1
3
Pixel 3 only used a few dynamic modules. There are 8 built from the Qualcomm audio teckpack along with the Qualcomm Atheros driver, seemingly just because it's how those drivers are being developed. The touchscreen driver is also a module since it's different for the 3 and 3 XL.
1
2
I prefer shipping fully static kernels specialized for each device as much as possible for minimal attack surface. I make the same change on the Pixel 2 and 2 XL, which have dynamic modules for Atheros (identical on both) and 4 variant-specific drivers in the standard releases.
Replying to
The same concepts apply SELinux policy, which Android splits into a system and vendor policy. Each device ships a specialized vendor policy, even including making lists of permitted ioctl commands for different drivers, like a list of permitted GPU driver commands on the device.
1