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@<<<
>
In the version of Gforth which I have (0.7.9_20220120),
fp@ 32769 - c@
*the terminal*:5:13: error: Floating-point stack overflow
fp@ 32769 - >>>c@<<<
However,
fp@ 65536 - c@ ok 1
and, worse,
1 fp@ 65536 - c! ok
So the guard pages are not a solution to pointer arithmetic bugs with
the stack pointers.
To make stack access memory safe, there has to be bounds checks on
reading and writing from/to stacks. This suggests that stacks should be
arrays and stack operations always involve array read/write from arrays
with enforced bounds checking e.g. something like
: DUP STACK[ tos ]@ ; \ TOS returns an index to the top of the stack
: OVER STACK[ tos 1+ ]@ ;
etc. and ]@ and ]! performs bounds checks.
I haven't yet looked at your paper on SafeForth.
--
Krishna
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
