Google Posts Patches So The Linux Kernel Can Be LTO-Optimized By Clang

[Zan Lynx]

The performance benefits of PGO widely eclipses those of LTO in my experience. I agree that for most applications it doesn't matter, but the same is true for LTO. However, for cpu intensive stuff, PGO give me ~5-20% performance increase.

Agreed. I worked on a software project a few years ago which was a library. Doing PGO on it was worth about 15% improvement. It already had a pretty good test suite: about 75% branch coverage (that is actually really good in my experience. Just imagine needing to fake out every disk operation and "malloc()" for failure testing: We didn't.) and the profile step just had to run the tests with the right amount of weight given to common operations. Such as doing successful operations instead of error path tests.

[Hugh]

In addition to the performance focus of LTO, the other motive for Google LTO'ing the kernel is for enabling Clang Control-Flow Integrity (CFI) in conjunction with LTO.

Why is that useful for the kernel?
CFI seems to find C++ bugs https://clang.llvm.org/docs/ControlFlowIntegrity.html
None seem to apply to C code.
The kernel has no C++ code.

[Zan Lynx]

Why is that useful for the kernel?
CFI seems to find C++ bugs https://clang.llvm.org/docs/ControlFlowIntegrity.html
None seem to apply to C code.
The kernel has no C++ code.

You missed everything under "indirect function call checking."

The Linux kernel uses a lot of indirect function calls. That's every call through a function pointer. The entire kernel module system relies on indirect function calls.

Plus, I believe that if you compile for the right CPU types clang and GCC will use hardware support for CFI. That means that if any code jumps to a function, it has to arrive at a special marker instruction or abort the program. That makes ROP abuse hard because malware can no longer jump into the middle of a useful function.

https://www.redhat.com/en/blog/fighting-exploits-control-flow-integrity-cfi-clang

https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

[Hugh]

You missed everything under "indirect function call checking."

The Linux kernel uses a lot of indirect function calls. That's every call through a function pointer. The entire kernel module system relies on indirect function calls.

Plus, I believe that if you compile for the right CPU types clang and GCC will use hardware support for CFI. That means that if any code jumps to a function, it has to arrive at a special marker instruction or abort the program. That makes ROP abuse hard because malware can no longer jump into the middle of a useful function.

https://www.redhat.com/en/blog/fight...rity-cfi-clang
https://software.intel.com/sites/def...gy-preview.pdf

Ahh. Thanks.

My code is almost always type-checked and type-checkable statically, including and especially function pointers. The very few exceptions are checked (by hand) very carefully. I don't know about kernel code.

Although void * can point at any object in C, a function isn't an object. The C standard doesn't really provide an equivalent for pointers to functions. Unless it was added since I last looked carefully.

Putting a marker instruction on each function's object code certainly should not require anything like LTO. Why would it not be a completely separate flag?

Double ahh: after posting I saw the URLs. So this is catching function pointers overwritten at run-time. Not bad type-punning.