non-executable stack question - Linux

This is a discussion on non-executable stack question - Linux ; Hi, Is there a way to make non-executable the stack (or the heap) of a process without patching the kernel? Is there any LKM that can do this or any text about this? Thanks in advance, rbtqwt....

+ Reply to Thread
Results 1 to 3 of 3

Thread: non-executable stack question

  1. non-executable stack question

    Hi,
    Is there a way to make non-executable the stack (or the heap) of a
    process without patching the kernel?
    Is there any LKM that can do this or any text about this?

    Thanks in advance,
    rbtqwt.


  2. Re: non-executable stack question

    rbtqwt@gmail.com writes:

    > Is there a way to make non-executable the stack (or the heap) of a
    > process without patching the kernel?


    On which platform?

    On the original x86, there is no separate eXecute bit, so if the
    memory is readable, it is also executable. You can make your stack
    non-executable by mprotect(2)ing it with no PROT_READ, but your
    program will not execute very far past that call

    OTOH, on x86_64 (and recent Intel x86 processors), a separate
    eXecute bit has been introduced, and on these processors you can
    make your stack non-executable (with the same mprotect()) if the
    kernel hasn't done that already.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: non-executable stack question

    >Is there a way to make non-executable the stack (or the heap) of a
    >>process without patching the kernel?


    > On which platform?
    >
    > On the original x86, there is no separate eXecute bit, so if the
    > memory is readable, it is also executable.


    Clever use by lowering the segment limit for the %cs selector
    to less than 0xfffff [1M] pages [@ 4KB], allows the kernel to
    simulate some important aspects of "no-execute stack, no-execute
    [most] .data." This takes advantage of the usual setup where
    the addresses in a main program have the relationship
    .text < .data < .bss < stack.
    Note that shared libraries, which also need coverage by %cs,
    historically lived between .bss and stack, so "no-execute .data"
    could not be supported. However, some Linux distributions
    now 'prelink' shared libraries to live below the usual .text
    of most main programs, which increases the effectiveness of
    lowering the segment limit on %cs. These ideas are a couple
    years old; Fedora Core 3 used them in Nov.2004. Also,
    see the manual page for the 'execstack' utility program,
    and the PT_GNU_STACK Elf32_Phdr.p_type in .

    --

+ Reply to Thread