Announcement

Collapse
No announcement yet.

Linux 4.9 On x86_64 To Support Vmapped Stacks

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

  • Linux 4.9 On x86_64 To Support Vmapped Stacks

    Phoronix: Linux 4.9 On x86_64 To Support Vmapped Stacks

    With the forthcoming Linux 4.9 kernel, x86_64 builds will support CONFIG_VMAP_STACK where kernel stacks are allocated with vmalloc_node for greater security...

    http://www.phoronix.com/scan.php?pag...ASM-Vmap-Stack

  • #2
    Cool, more stuff from GrSecurity. Question, why in assembly and not C?
    Developer of Ultracopier/Supercopier and of the game CatchChallenger

    Comment


    • #3
      Is this feature available to C/C++ via binutils+gcc in general, or is it only kernel-specific for now?

      Comment


      • #4
        Originally posted by alpha_one_x86 View Post
        Cool, more stuff from GrSecurity. Question, why in assembly and not C?
        Probably performance reasons, otherwise too many would whine about Grsec features "slowing down performance" (as they already do).

        What I want to know is with all of these Grsec security features coming to all Linux kernels, will they even be enabled in distros?

        Comment


        • #5
          0 (zero) no longer disables cursor blinking in org-netbeans-modules-editor-settings-CustomPreferences.xml - use 2147483647 (24.8 days) instead.

          Comment


          • #6
            Originally posted by alpha_one_x86 View Post
            Cool, more stuff from GrSecurity. Question, why in assembly and not C?
            i interpret article as "grsecurity's hack did not support kasan, this feature supports kasan"

            Comment


            • #7
              Originally posted by atomsymbol View Post
              Is this feature available to C/C++ via binutils+gcc in general, or is it only kernel-specific for now?
              ??? userspace has no access to physical memory, its stacks were always virtually mapped with guard page

              Comment


              • #8
                Originally posted by pal666 View Post
                ??? userspace has no access to physical memory, its stacks were always virtually mapped with guard page
                The current state-of-the-art stack overflow reporting in Linux:

                Code:
                $ cat a.c
                int f() { return 1+f(); }
                int main() { return f(); }
                
                $ gcc -g -o loop a.c
                
                $ gdb ./loop 
                (gdb) disass f
                Dump of assembler code for function f:
                   0x00000000004004a6 <+0>:     push   %rbp
                   0x00000000004004a7 <+1>:     mov    %rsp,%rbp
                   0x00000000004004aa <+4>:     mov    $0x0,%eax
                   0x00000000004004af <+9>:     callq  0x4004a6 <f>
                   0x00000000004004b4 <+14>:    add    $0x1,%eax
                   0x00000000004004b7 <+17>:    pop    %rbp
                   0x00000000004004b8 <+18>:    retq
                (gdb) run
                Starting program: ./loop 
                Program received signal SIGSEGV, Segmentation fault.
                0x00000000004004af in f () at a.c:1
                1               return 1+f();
                A better stack overflow reporting would be:

                Code:
                (gdb) run
                Starting program: ./loop 
                Program received signal SIGSTACK, Stack overflow.
                0x00000000004004af in f () at a.c:2
                1               return 1+f();

                Comment


                • #9
                  Originally posted by alpha_one_x86 View Post
                  Cool, more stuff from GrSecurity. Question, why in assembly and not C?
                  Just guessing, but since it appears specific to x86_64, there's no need for it to be cross-platform.

                  Comment


                  • #10
                    Originally posted by atomsymbol View Post
                    Program received signal SIGSTACK, Stack overflow.
                    it has nothing to do with kernel change described in article and i highly doubt someone will add another flag to memory pages and another signal just to change word segv to stack for your pleasure

                    Comment

                    Working...
                    X