Announcement

Collapse
No announcement yet.

FGKASLR Revised For Better Linux Security Via Enhanced Address Space Randomization

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

  • FGKASLR Revised For Better Linux Security Via Enhanced Address Space Randomization

    Phoronix: FGKASLR Revised For Better Linux Security Via Enhanced Address Space Randomization

    One of many high profile features that didn't make it in time for Linux 5.8 is FGKASLR, Function Granular Kernel Address Space Layout Randomization...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Checking for an obvious solution turns up little more than a dozen results and there are definitely some new patches to be found and applied, but an earlier Phoronix article on LTO didn't examine it's application (and combination with FGKASLR); if you are going to do performance benchmarking.

    Comment


    • #3
      I found some interesting bugs in games under KVM with ASLR and 3200MHz CL14 RAM. Bugs are mostly related to texture rendering, but 100% reproducible by switching ASLR.

      I'm wondering if FGKASLR will make it better or worse and if any distros are planning to enable it by default once it's merged.

      Interesting to see that this only works on X86_64. The author gave some examples of performance, but was relative to KASLR. More latency/bandwidth testing could be useful for FGKASLR/KASLR/ASLR/No-randomization.

      Comment


      • #4
        Originally posted by Jabberwocky View Post
        I found some interesting bugs in games under KVM with ASLR and 3200MHz CL14 RAM. Bugs are mostly related to texture rendering, but 100% reproducible by switching ASLR.

        I'm wondering if FGKASLR will make it better or worse and if any distros are planning to enable it by default once it's merged.

        Interesting to see that this only works on X86_64. The author gave some examples of performance, but was relative to KASLR. More latency/bandwidth testing could be useful for FGKASLR/KASLR/ASLR/No-randomization.
        ASLR is user-space, so there should be no change there.

        KASLR should have negligible impact over non-KASLR. The way it works in the kernel is that it is still position-dependent, it's just re-linked at boot time to a random base address -- but it behaves the same way it would if it had originally been linked to run at that address. Disabling KASLR should shave a millisecond or so from boot time maybe but that's it.

        FGKASLR actually changes the layout of the kernel code (i.e. which functions are close to which functions) so it has a measurable performance impact.

        Comment

        Working...
        X