Re: Direction of Stack Growth - Embedded

This is a discussion on Re: Direction of Stack Growth - Embedded ; On Oct 23, 11:33 am, glen herrmannsfeldt wrote: > Archi wrote: > > (I wrote) > > >> Many systems now access arguments as positive index off > >> the stack pointer, and local variables as negative > >> index ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: Direction of Stack Growth

  1. Re: Direction of Stack Growth

    On Oct 23, 11:33 am, glen herrmannsfeldt
    wrote:
    > Archi wrote:
    >
    > (I wrote)
    >
    > >> Many systems now access arguments as positive index off
    > >> the stack pointer, and local variables as negative
    > >> index off the stack pointer. (or frame pointer.)

    > > sorry, no way with hardware stack pointer. Do not forget that there are
    > > uncontrollable events like interrupts, so stack should be completely
    > > "down" all the time - there is no need for negative indexes. If you use
    > > frame pointer - then yes? but you pay wit extra register and "entry" code.

    >
    > Most now have a separate stack for interrupts and other system
    > functions, pretty much needed for any protected mode system.
    >
    > I do remember from the 8080 days someone working on the
    > design of a terminal. It was found that the fastest way to
    > clear the screen memory was to point the stack pointer at
    > one end of the buffer and push blanks. Mysterious characters
    > kept appearing on the screen, though, which turned out to be
    > due to interrupts during the clear loop.
    >
    > -- glen


    Check this out.
    http://kstruct.com/2007/04/16/interv...ack-direction/

    Interesting
    1) The author claims as below in that link -
    "Wikipedia tells me that most modern OSes grow the stack down which
    is odd given the security advantages of doing it up."
    Is that true or some kind of wrong information in internet ?

    2) But i liked the 'C' program that helps in finding the direction of
    stack growth.
    3) I also like the shell script mentioned in the link ->
    http://www.splode.com/~friedman/soft...tack-direction

    Thx in advans,
    Karthik Balaguru


  2. Re: Direction of Stack Growth

    On Oct 23, 11:25 am, karthikbalaguru
    wrote:
    > On Oct 23, 11:33 am, glen herrmannsfeldt
    > wrote:
    >
    >
    >
    >
    >
    > > Archi wrote:

    >
    > > (I wrote)

    >
    > > >> Many systems now access arguments as positive index off
    > > >> the stack pointer, and local variables as negative
    > > >> index off the stack pointer. (or frame pointer.)
    > > > sorry, no way with hardware stack pointer. Do not forget that there are
    > > > uncontrollable events like interrupts, so stack should be completely
    > > > "down" all the time - there is no need for negative indexes. If you use
    > > > frame pointer - then yes? but you pay wit extra register and "entry" code.

    >
    > > Most now have a separate stack for interrupts and other system
    > > functions, pretty much needed for any protected mode system.

    >
    > > I do remember from the 8080 days someone working on the
    > > design of a terminal. It was found that the fastest way to
    > > clear the screen memory was to point the stack pointer at
    > > one end of the buffer and push blanks. Mysterious characters
    > > kept appearing on the screen, though, which turned out to be
    > > due to interrupts during the clear loop.

    >
    > > -- glen

    >
    > Check this out.http://kstruct.com/2007/04/16/interv...ack-direction/
    >
    > Interesting
    > 1) The author claims as below in that link -
    > "Wikipedia tells me that most modern OSes grow the stack down which
    > is odd given the security advantages of doing it up."
    > Is that true or some kind of wrong information in internet ?
    >
    > 2) But i liked the 'C' program that helps in finding the direction of
    > stack growth.
    > 3) I also like the shell script mentioned in the link ->http://www.splode.com/~friedman/soft...tack-direction
    >
    > Thx in advans,
    > Karthik Balaguru- Hide quoted text -
    >
    > - Show quoted text -


    I posted that from my query regarding 'Direction of Stack Growth'
    posted in other groups.
    I saw that i missed comp.os.linux.embedded and hence posted it here.

    Kindly share your ideas in the following link :
    http://groups.google.co.in/group/com...95ebc0/?hl=en#

    Thx,
    Karthik Balaguru



  3. Re: Direction of Stack Growth

    On Oct 23, 11:25 am, karthikbalaguru
    wrote:
    > On Oct 23, 11:33 am, glen herrmannsfeldt
    > wrote:
    >
    >
    >
    >
    >
    > > Archi wrote:

    >
    > > (I wrote)

    >
    > > >> Many systems now access arguments as positive index off
    > > >> the stack pointer, and local variables as negative
    > > >> index off the stack pointer. (or frame pointer.)
    > > > sorry, no way with hardware stack pointer. Do not forget that there are
    > > > uncontrollable events like interrupts, so stack should be completely
    > > > "down" all the time - there is no need for negative indexes. If you use
    > > > frame pointer - then yes? but you pay wit extra register and "entry" code.

    >
    > > Most now have a separate stack for interrupts and other system
    > > functions, pretty much needed for any protected mode system.

    >
    > > I do remember from the 8080 days someone working on the
    > > design of a terminal. It was found that the fastest way to
    > > clear the screen memory was to point the stack pointer at
    > > one end of the buffer and push blanks. Mysterious characters
    > > kept appearing on the screen, though, which turned out to be
    > > due to interrupts during the clear loop.

    >
    > > -- glen

    >
    > Check this out.http://kstruct.com/2007/04/16/interv...ack-direction/
    >
    > Interesting
    > 1) The author claims as below in that link -
    > "Wikipedia tells me that most modern OSes grow the stack down which
    > is odd given the security advantages of doing it up."
    > Is that true or some kind of wrong information in internet ?
    >
    > 2) But i liked the 'C' program that helps in finding the direction of
    > stack growth.
    > 3) I also like the shell script mentioned in the link ->http://www.splode.com/~friedman/soft...tack-direction
    >
    > Thx in advans,
    > Karthik Balaguru- Hide quoted text -
    >
    > - Show quoted text -


    Hi,
    I missed comp.os.linux.embedded while posting the query regarding
    'Direction of Stack Growth'.
    So, I have posted it here.

    Kindly share your views for the thread mentioned below :
    http://groups.google.co.in/group/com...95ebc0/?hl=en#

    Thx,
    Karthik Balaguru


  4. Re: Direction of Stack Growth

    On Oct 23, 1:25 am, karthikbalaguru
    wrote:
    > Interesting
    > 1) The author claims as below in that link -
    > "Wikipedia tells me that most modern OSes grow the stack down which
    > is odd given the security advantages of doing it up."
    > Is that true or some kind of wrong information in internet ?



    It's a common misconception that an upwards growing stack is less
    vulnerable to buffer overflow/stack smashing attacks. In one limited
    case that's semi-correct, where the buffer being overflowed is in the
    routine that is doing the overflowing, and there is no active return
    address on the stack after the overflowed buffer. Unfortunately the
    vast majority of real stack smashes use subroutines to do the dirty
    work in a buffer owned by a caller. That just moves the point at
    which the bad return address is used. Consider:

    void f(void)
    {
    char s[4];
    strcpy(s, "abcdefghjklmnopqrstuvwxyz");
    }

    With a typical downward growing stack, the smashed return address will
    be the one from f(). With an upwards growing stack, it'll be the
    return from strcpy() that's altered. Not exactly a huge improvement.

    And the stack growth direction doesn't do anything to prevent the
    corruption of any other items in the same stack frame that are places
    after the buffer in question, or any items following an overflowed
    buffer anywhere in the system. Consider what happens if the string in
    the following structure is overflowed (again, assuming typical layout
    in memory):

    struct st {char s[4]; void (*fp)(void);};

    In any event, the Wikipedia page on the subject was edited a couple of
    months ago to eliminate the claim.



  5. Re: Direction of Stack Growth


    In article <1193129323.588079.51960@z24g2000prh.googlegroups.c om>,
    "robertwessel2@yahoo.com" writes:
    |> On Oct 23, 1:25 am, karthikbalaguru
    |> wrote:
    |> > Interesting
    |> > 1) The author claims as below in that link -
    |> > "Wikipedia tells me that most modern OSes grow the stack down which
    |> > is odd given the security advantages of doing it up."
    |> > Is that true or some kind of wrong information in internet ?
    |>
    |> It's a common misconception that an upwards growing stack is less
    |> vulnerable to buffer overflow/stack smashing attacks. In one limited
    |> case that's semi-correct, where the buffer being overflowed is in the
    |> routine that is doing the overflowing, and there is no active return
    |> address on the stack after the overflowed buffer. Unfortunately the
    |> vast majority of real stack smashes use subroutines to do the dirty
    |> work in a buffer owned by a caller. That just moves the point at
    |> which the bad return address is used. ...

    There is another case, too, but it is rarer. Using a value that is
    MUCH too large is more likely to cause a SIGSEGV than to trash some
    frames much higher up the tree.

    However, that does not deny your point, with which I agree.


    Regards,
    Nick Maclaren.


  6. Re: Direction of Stack Growth

    On Oct 23, 1:48 pm, "robertwess...@yahoo.com"
    wrote:
    > On Oct 23, 1:25 am, karthikbalaguru
    > wrote:
    >
    > > Interesting
    > > 1) The author claims as below in that link -
    > > "Wikipedia tells me that most modern OSes grow the stack down which
    > > is odd given the security advantages of doing it up."
    > > Is that true or some kind of wrong information in internet ?

    >
    > It's a common misconception that an upwards growing stack is less
    > vulnerable to buffer overflow/stack smashing attacks. In one limited
    > case that's semi-correct, where the buffer being overflowed is in the
    > routine that is doing the overflowing, and there is no active return
    > address on the stack after the overflowed buffer. Unfortunately the
    > vast majority of real stack smashes use subroutines to do the dirty
    > work in a buffer owned by a caller. That just moves the point at
    > which the bad return address is used. Consider:
    >
    > void f(void)
    > {
    > char s[4];
    > strcpy(s, "abcdefghjklmnopqrstuvwxyz");
    >
    > }
    >
    > With a typical downward growing stack, the smashed return address will
    > be the one from f(). With an upwards growing stack, it'll be the
    > return from strcpy() that's altered. Not exactly a huge improvement.
    >
    > And the stack growth direction doesn't do anything to prevent the
    > corruption of any other items in the same stack frame that are places
    > after the buffer in question, or any items following an overflowed
    > buffer anywhere in the system. Consider what happens if the string in
    > the following structure is overflowed (again, assuming typical layout
    > in memory):
    >
    > struct st {char s[4]; void (*fp)(void);};
    >
    > In any event, the Wikipedia page on the subject was edited a couple of
    > months ago to eliminate the claim.


    Check this link . Collected some more information from internet :-
    http://diku.edu/hjemmesider/ansatte/...cs_a4_11pt.pdf

    I got some interesting info from the sections 8.8.2, 9.8.3 and 9.8.4.
    Interesting !!

    9.8.3 Direction of stack-growth and position of FP
    ----------------------------------------------------------------------------
    There is no particular reason why a stack has to grow upwards in
    memory. It is, in
    fact, more common that call stacks grow downwards in memory. Sometimes
    the choice
    is arbitrary, but at other times there is an advantage to have the
    stack growing in a
    particular direction. Some instruction sets have memory-access
    instructions that include
    a constant offset from a register-based address. If this offset is
    unsigned (as it is on,
    e.g., IBM System/370), it is an advantage that all fields in the
    activation record are at
    non-negative offsets. This means that either FP must point to the
    bottom of the frame
    and the stack grow upwards, or FP must point to the top of the frame
    and the stack grow
    downwards.

    If, on the other hand, offsets are signed but have a small range (as
    on Digital's Vax,
    where the range is -128 - +127), it is an advantage to use both
    positive and negative
    offsets. This can be done, as suggested in section 9.8.2, by placing
    FP after the parameters
    but before the rest of the frame, so parameters are addressed by
    negative offsets and
    the rest by positive. Alternatively, FP can be positioned k bytes
    above the bottom of the
    frame, where k is the largest negative offset

    9.8.2 Variable number of parameters
    ------------------------------------------------------
    Some languages (e.g., C and LISP) allow a function to have a variable
    number of parameters.
    This means that the function can be called with a different number of
    parameters
    at each call. In C, the printf function is an example of this.
    The layouts we have shown in this chapter all assume that there is a
    fixed number of
    arguments, so the offsets to, e.g., local variables are known. If the
    number of parameters
    can vary, this is no longer true.

    One possible solution is to have two frame pointers: One that shows
    the position
    of the first parameter and one that points to the part of the frame
    that comes after the
    parameters. However, manipulating two FP's is somewhat costly, so
    normally another
    trick is used: The FP points to the part of the frame that comes after
    the parameters,
    Below this, the parameters are stored at negative offsets from FP,
    while the other parts
    of the frame are accessed with (fixed) positive offsets. The
    parameters are stored such
    that the first parameter is closest to FP and later parameters further
    down the stack. This
    way, parameter number k will be a fixed offset ( 4 k) from FP.
    When a function call is made, the number of arguments to the call is
    known to the
    caller, so the offsets (from the old FP) needed to store the
    parameters in the new frame
    will be fixed at this point.

    Alternatively, FP can point to the top of the frame and all fields can
    be accessed by
    fixed negative offsets. If this is the case, FP is sometimes called
    SP, as it points to the
    top of the stack.

    9.8.4 Register stacks
    -----------------------------------
    Some processors, e.g., Suns Sparc and Intels IA-64 have on-chip stacks
    of registers. The
    intention is that frames are kept in registers rather than on a stack
    in memory. At call
    or return of a function, the register stack is adjusted. Since the
    register stack has a finite
    size, which is often smaller than the total size of the call stack, it
    may overflow. This
    is trapped by the operating system which stores part of the stack in
    memory and shifts
    the rest down (or up) to make room for new elements. If the stack
    underflows (at a pop
    from an empty register stack), the OS will restore earlier saved parts
    of the stack.

    Thx,
    Karthik Balaguru


  7. Re: Direction of Stack Growth

    karthikbalaguru wrote:

    (snip)

    > Check this out.
    > http://kstruct.com/2007/04/16/interv...ack-direction/

    (snip)

    > 2) But i liked the 'C' program that helps in finding the direction of
    > stack growth.


    I would say technically that only finds the direction of stack
    growth relative to that of array addressing. If one addressed arrays
    downward in memory, then the C conversion for pointer arithmetic,
    including that for pointer differences, would invert the sign.

    In addition, the C standard makes no guarantee on tests other than
    equality and inequality between pointers to different objects.

    I think we really need a C compiler for the 7090 so we can check
    out the effects of sign magnitude arithmetic and negative indexing
    arrays. (The latter not required, but Fortran did it.)

    -- glen


+ Reply to Thread