From: krishna.myneni@ccreweb.org   
      
   On 3/2/24 10:43, Anton Ertl wrote:   
   > Krishna Myneni  writes:   
   >> On 3/2/24 10:08, Krishna Myneni wrote:   
   >>> === Gforth example ===   
   >>> : rt1 recurse ;  ok   
   >>> rt1   
   >>> *the terminal*:2:1: error: Return stack overflow   
   >>>   >>>rt1<<<   
   >>> === end example ===   
   >>>   
   >>   
   >> To be clear, if you try to fill up the fp or data stack, as with your   
   >> rt1 example, kForth does give a segfault (and hence is susceptible to an   
   >> exploit), while Gforth still gives the same error.   
   >   
   > In Gforth on a Unix system, Unix produces a SIGSEGV when a stack runs   
   > into a guard page.  The signal handler then looks at the offending   
   > address, and guesses that an access close to the bottom of a stack is   
   > an underflow of that stack, and correspondingly for accesses close to   
   > the top of a stack.  This can be seen as follows:   
   >   
   > With the gforth engine with the FP stack being empty:   
   >   
   > fp@ 32769 - c@   
   > *the terminal*:3:13: error: Floating-point stack overflow   
   > fp@ 32769 - >>>c@<<<   
   > fp@ 1+ c@   
   > *the terminal*:4:8: error: Floating-point stack underflow   
   > fp@ 1+ >>>c@<<<   
   >   
      
   Nice. The use of guard pages is something I need to look into to avoid   
   memory leaks or corruption for the stacks. Does this mean Gforth is   
   immune to arbitrary code execution attacks for the fp and data stack   
   overflow and underflow conditions?   
      
   --   
   Krishna   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)