Announcement

Collapse
No announcement yet.

Linux 5.13 Poised To Allow Randomizing Kernel Stack Offset At Each System Call

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

  • Linux 5.13 Poised To Allow Randomizing Kernel Stack Offset At Each System Call

    Phoronix: Linux 5.13 Poised To Allow Randomizing Kernel Stack Offset At Each System Call

    The ability to randomize the kernel stack offset at each system call looks like it will land for the upcoming Linux 5.13 cycle. This optional feature makes it much more difficult to carry out stack-based attacks on the Linux kernel...

    https://www.phoronix.com/scan.php?pa...k-Syscall-5.13

  • #2
    Forgive me for the noobish question but how does this compare to what OpenBSD does with relinking the kernel after each boot? Is this the same except on steroids where it does it after every system call practically or is this something entirely different?

    Comment


    • #3
      @kylew77
      It's not about randomizing kernel code locations and/or contents.
      It's about randomizing the location in memory where kernel code will store volatile temporary data (stack) like return points and arguments/variables on subroutine calls during the very syscall (and so each new syscall gets random stack location assigned making stack based attacks / attack calculations unable to determine where exactly stuff should land).
      Last edited by Alex/AT; 09 April 2021, 07:29 AM.

      Comment


      • #4
        I wonder if we wouldn't be better of without all the address randomisation and shouldn't instead make debugging potential vulnerabilities easier making the attack surface smaller by fixing bugs instead of hiding them? A lot of efficiency and potential optimisations are also sacrificed here with the full suite of obfuscation techinques.

        Comment


        • #5
          we would not.

          because debugging and fixing bugs you know about can only take you so far. you have to prepare for the unknown potential problems as well, to an extent.

          there are many security issues that stem from hardware faults or unexpected behaviour of the hardware. perfect code won't ever protect you from them. nor from ones that are caused by misbehaving userspace apps.

          having multiple layers of security is better that having one and hoping for the best. and perfectly secure code that actually does something may exist on paper but not in reality. an unexpected glitch, quirk of one of the chips, or a person/device randomly shorting circuits on the mainboard is not something you can plan for.
          Last edited by yoshi314; 09 April 2021, 09:29 AM.

          Comment


          • #6
            Originally posted by s_j_newbury View Post
            I wonder if we wouldn't be better of without all the address randomisation and shouldn't instead make debugging potential vulnerabilities easier making the attack surface smaller by fixing bugs instead of hiding them? A lot of efficiency and potential optimisations are also sacrificed here with the full suite of obfuscation techinques.
            Sure, we just need to write perfect code.

            Comment

            Working...
            X