On Thu, 30 Jul 1998 02:13:26 +1000, "John D. Hardin" <jhardinat_private> wrote: >On Tue, 28 Jul 1998, Cy Schubert wrote: > >> What makes MVS (and VM) so impervious to attack is that the S/390 >> hardware doesn't rely on a stack, making effective buffer overruns >> considerably more difficult. (A little off topic :) Re-entrant and recursive functions are also considerably more difficult :-(. (And the return address will still wind up in memory unless you're calling a leaf routine). >I wonder how feasible it would be to modify GCC to generate code with two >stacks (or something equivalent): one for local variables, the other for >parameters and return addresses. How about FORTH :-)? A couple of problems: 1) Supporting a second stack efficiently would need kernel support (it could be emulated in a user-land signal handler but would be much more expensive). 2) Putting the parameters and return address on the same stack makes sense for SPARC (and other register-window architectures). For the x86 architecture, it makes more sense to put the parameters onto the variable stack (this leaves EBP for data and ESP for addresses). Overall, though, the benefits probably outweigh the costs. >Or how about allocating space for all local variables from the system heap >automatically and transparently rather than placing them on the stack? The hard part is freeing them again. Unwinding a stack is easy because it's LIFO. How do you work out which pieces of heap to free after you do a longjmp? >Or how about automatically allocating space just for local strings? I'm not sure what this means. C has no concept of a `string'. Peter -- Peter Jeremy (VK2PJ) peter.jeremyat_private Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:10:38 PDT