OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 4th quarter (Oct-Dec) 1998: More about multi-stack allocator.

More about multi-stack allocator.

Serge Orlov (sorlovCON.MCST.RU)
Wed, 28 Oct 1998 16:12:30 +0300 

  Hi,
I received some questions about multi-stack allocator, here is
the answers:


> how about performance compare with "canary" and "stack guard"?

Author of StackGuard wrote to me about multi-stack:
    > Way cool...
    > ...
    > Your performance figures are very impressive.


 StackGuard puts "canaries" into every function (at least in the
current version). In contrast multi-stack allocator is used only
for local arrays and does not affect functions without local arrays.
So if a program spends most of time in functions without arrays,
it is even hard to measure slowdown. If a program uses arrays, then
the slowdown is about 1%. That is lower than with StackGuard.
 The main difference is memory. StackGuard almost does not increase
memory consumption, while multi-stacked program can use a lot of
additional memory. Reread my first post for figures. Fortunately,
memory is cheap nowadays.

> So how compatible is it?  Can it inter-operate with standard shared
> libraries?  Do you just have to re-compile the shared libraries?

 You can mix multi-stacked programs and shared libraries in all possible
ways. Well, at least on elf-i386-linux, other platforms may need some
porting and checking.
 Shared libraries are also easy to recompile. Just add -fmulti-stack
option.

 Crispin Cowan also noted that the C standard states that automatic
variables are to be laid out in sequential memory, although some padding
is allowed. OK, I'll add this to "Limitations" paragraph, but I have not
seen any programs that depend on layout of automatic variables.



                                      Serge Orlov <sorlovcon.mcst.ru>.