[Google Pixel 3 XL ROMs, Kernels, Recoveries, & Oth] Freak07:
To get the thread a bit back on topic, also development wise.

Any battery gains by removing security features like LTO in combination with CFI are compared to the actual saved energy vs security correlation, negligible in my opinion.

Most of the work is done at compile time. That´s why it takes significantly more time to compile the kernel with LTO enabled! (5 minutes for the actual kernel plus 15 minutes on top for LTO on my machine!)

If disabling LTO and CFI gives 5 minutes (that´s an estimation) more SOT at the end of the day, I happily have both of those enabled as they contribute quite a lot to security. This may not matter to some but it does for me. What´s the point of upstreaming a kernel (which in itself contributes to stability but also a lot to security) if I disable other additional security features. If more battery life is needed simply activate the battery saving in settings or decrease screen brightness by just a notch.

The actual energy consumption, that may be caused by LTO and CFI enabled at kernel level, is probably very low on the list of components that drain power (order may be subject to change ;), it´s just a quick writeup! ):

1. Screen

2. Mobile Network

3. WiFi

4. CPU

5. Badly optimized apps

6. Location services

...

...

...

...

Security features as CFI and LTO

Google´s implementation of Control Flow Integrity (CFI) in the kernel imposes minimal (next to none) overhead. As already said most of the work is done at compile time.

Take a look at the documentation:

Quote from the documentation:

Control flow integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.

In Android 9, we enabled LLVM's implementation of CFI in more components and also in the kernel. System CFI is on by default, but you need to enable kernel CFI. (enabled by default on Pixel 3/XL)

LLVM's CFI requires compiling with Link-Time Optimization (LTO). LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.

If used correctly CFI and LTO contribute to security as well as fixed code. On this note, next release will have wireguard fixed! Thanks to [MENTION=5434776]zx2c4[/MENTION] !

To better understand the impact of CFI take also a look at this slide!

The gist of all this is that nearly every software contains bugs. The linux-kernel contains probably a lot of them which are not fixed and not yet discovered. A tiny minority of these may cause real security holes. Now there are basically two different approaches to close exactly these bugs.

You can try to detect and fix every bug separately. While this may be the desired road of action it´s simple impossible to achieve at this point due to the number of bugs, also due to limitation current programming languages impose on the code.

The other approach is to put an additional layer of security like CFI on it. It´s a defense in depth feature that not aims to fix these bugs but to mitigate the damage these bugs can do. (Tripping CFI simply shuts down the phone as were the reason of the wireguard reboots).

This approach is called hardening! We harden the software but adding a "relatively" small layer of code on top that increases security, in the hope that as time goes by these security holes are properly fixed in the kernel.

I did add more hardening before in release 1.7.0, by adding some memory overflow protection mechanisms.

This way CFI actually contributes as a hardening tool to the security of the software (our kernel) as well as a debugging tool to detect kernel bugs and possible exploits which may be used as a point of attack.

Google did put a lot of time and resources into optimizing these features!