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...

    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
    Cool, more stuff from GrSecurity. Question, why in assembly and not C?
    Developer of Ultracopier/CatchChallenger and CEO of Confiared

    Comment


    • #3
      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


      • #4
        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


        • #5
          Originally posted by atomsymbol
          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


          • #6
            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


            • #7
              Originally posted by atomsymbol
              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


              • #8
                Originally posted by atomsymbol
                Why did you suffix your response with "for your pleasure"?
                because it is the only reason

                Comment


                • #9
                  Originally posted by atomsymbol

                  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
                  [U][B]Program received signal SIGSEGV, Segmentation fault.[/B][/U]
                  0x00000000004004af in f () at a.c:1
                  1 return 1+f();
                  A better stack overflow reporting would be:

                  Code:
                  (gdb) run
                  Starting program: ./loop
                  [U][B]Program received signal SIGSTACK, Stack overflow.[/B][/U]
                  0x00000000004004af in f () at a.c:2
                  1 return 1+f();
                  It could do that easily if the overflow is caused by a push instruction, but those are the simplest cases and most harmless of the stack overflows. The tipical stack overflow that guard pages try to prevent is writing more data into an array than its capacity.

                  That will tipically translate into a MOV with a base address that is a valid stack pointer and an offset that pushes it over the stack boundry. It couls also get there with a base address that is a valid heap address but the offset is some random value that happens to hit that guard page or even a random base address that is inside the guard page.

                  To cover all cases the kernel would need some form of artificial intelligence to analize what the program was doing, so they decided to rely on the natural intelligence of developers to figure it out.

                  Comment

                  Working...
                  X