Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by Grinch View Post
    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.

    Comment


    • #42
      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.

      Comment


      • #43
        Originally posted by Hugh View Post
        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/fight...rity-cfi-clang
        https://software.intel.com/sites/def...gy-preview.pdf

        Comment


        • #44
          Originally posted by Zan Lynx View Post

          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.
          Last edited by Hugh; 07-12-2020, 09:23 PM.

          Comment

          Working...
          X