Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #18051 > unrolled thread

RfC: Foreword

Back to article view | Back to comp.lang.forth

Contents

  RfC: Foreword "Peter Knaggs" <pjk@bcs.org.uk> - 2012-12-17 19:40 +0000
    Re: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-17 17:40 -0500
      Re: Foreword "Elizabeth D. Rather" <erather@forth.com> - 2012-12-17 21:55 -1000
        Re: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-18 19:22 -0500
          Re: Foreword Peter Knaggs <pjk@bcs.org.uk> - 2012-12-19 10:03 +0000
            Re: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-21 02:39 -0500
            Re: Foreword "Elizabeth D. Rather" <erather@forth.com> - 2012-12-20 22:16 -1000
          Re: Foreword rickman <gnuarm@gmail.com> - 2012-12-19 16:09 -0500
            Re: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-21 02:20 -0500
          Re: Foreword "Ed" <invalid@nospam.com> - 2012-12-23 00:43 +1100
            Re: Foreword "A. K." <akk@nospam.org> - 2012-12-22 16:44 +0100
              Re: Foreword "Ed" <invalid@nospam.com> - 2012-12-27 19:54 +1100
                Re: Foreword Alex McDonald <blog@rivadpm.com> - 2012-12-27 05:36 -0800
                  Re: Foreword Alex McDonald <blog@rivadpm.com> - 2012-12-27 05:40 -0800
            Re: Foreword Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-22 10:07 -0600
    Re: RfC: Foreword "A. K." <akk@nospam.org> - 2012-12-18 08:27 +0100
      Re: RfC: Foreword Elizabeth D Rather <erather@forth.com> - 2012-12-17 22:24 -1000
        Re: RfC: Foreword "A. K." <akk@nospam.org> - 2012-12-18 20:38 +0100
          Re: RfC: Foreword "Elizabeth D. Rather" <erather@forth.com> - 2012-12-18 09:54 -1000
            Re: RfC: Foreword "A. K." <akk@nospam.org> - 2012-12-18 22:00 +0100
              Re: RfC: Foreword "Elizabeth D. Rather" <erather@forth.com> - 2012-12-18 11:21 -1000
                Re: RfC: Foreword "A. K." <akk@nospam.org> - 2012-12-20 07:56 +0100
                  Re: RfC: Foreword Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-20 03:38 -0600
                    Re: RfC: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-21 02:20 -0500
                      Re: RfC: Foreword Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-21 04:02 -0600
            Re: RfC: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-18 19:24 -0500
              Re: RfC: Foreword Alex McDonald <blog@rivadpm.com> - 2012-12-18 22:46 -0800
                Re: RfC: Foreword "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-21 02:21 -0500
                  Re: RfC: Foreword Alex McDonald <blog@rivadpm.com> - 2012-12-21 15:24 -0800

Page 2 of 2 — ← Prev page 1 [2]

#18074

On 12/18/12 11:00 AM, A. K. wrote:
> On 18.12.2012 20:54, Elizabeth D. Rather wrote:
>> The problem is, that there is *no* technical distinction between system
>> and program in Forth! That is one of its strengths, actually. All of the
>> I/O, compiler tools, and other building blocks are available to
>> programmers to use in their applications, and many do.
>>
>
> That's a bit of whistling always on the bright side of life ... ;-)
>
> Our compilates certainly did NOT contain the compiler words in the
> target. Nevertheless they were made from plain Forth sources.
>

I obviously can't speak for all system providers, but all Forth 
*development systems* I am familiar with make everything available to 
the user. Embedded applications often don't include a programming 
capability, but the standard is for a development system, and that is 
what the "Foreword" is for.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#18112

On 18.12.2012 22:21, Elizabeth D. Rather wrote:
>  Embedded applications often don't include a programming
> capability, but the standard is for a development system, and that is
> what the "Foreword" is for.

The title sheet of the standard document explicitly says
PROGRAMMING LANGUAGES -- FORTH
and not
DEVELOPMENT SYSTEMS -- FORTH

So it's about a LANGUAGE, it's syntax, semantics and all.
A Forth development SYSTEM is just a classic incarnation plus tools, 
just as Webster's Dictionary isn't English.

To repeat, IMO a good foreward should mention this distinction.

[toc] | [prev] | [next] | [standalone]

#18123

A. K. <akk@nospam.org> wrote:
> On 18.12.2012 22:21, Elizabeth D. Rather wrote:
>>  Embedded applications often don't include a programming
>> capability, but the standard is for a development system, and that is
>> what the "Foreword" is for.
> 
> The title sheet of the standard document explicitly says
> PROGRAMMING LANGUAGES -- FORTH
> and not
> DEVELOPMENT SYSTEMS -- FORTH
> 
> So it's about a LANGUAGE, it's syntax, semantics and all.
> A Forth development SYSTEM is just a classic incarnation plus tools, 
> just as Webster's Dictionary isn't English.
> 
> To repeat, IMO a good foreward should mention this distinction.

This distinction makes no sense for Forth.  It might make sense for C,
but not Forth, because Forth is different.  It's interactive.  It
gives you all the tools you need to run programs without invoking any
external commands.

Andrew.

[toc] | [prev] | [next] | [standalone]

#18157

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:cb6dneSCO-wHQU_NnZ2dnUVZ_qudnZ2d@supernews.com...
> A. K. <akk@nospam.org> wrote:
> > On 18.12.2012 22:21, Elizabeth D. Rather wrote:
> >>  Embedded applications often don't include a programming
> >> capability, but the standard is for a development system, and
> >> that is what the "Foreword" is for.
> >
> > The title sheet of the standard document explicitly says
> > PROGRAMMING LANGUAGES -- FORTH
> > and not
> > DEVELOPMENT SYSTEMS -- FORTH
> >
> > So it's about a LANGUAGE, it's syntax, semantics and all.
> > A Forth development SYSTEM is just a classic incarnation plus
> > tools, just as Webster's Dictionary isn't English.
> >
> > To repeat, IMO a good foreward should mention this
> > distinction.
>
> This distinction makes no sense for Forth.
...

> It might make sense for C,
> but not Forth, because Forth is different.

It's not that different, especially when it comes to other
interpreted languages, like BASIC or LOGO, etc.

>  It's interactive.

So are most BASICs.

> It gives you all the tools you need to run programs
> without invoking any external commands.
>

So do most BASICs.


I.e., A.K. appears to be correct to me.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#18162

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:cb6dneSCO-wHQU_NnZ2dnUVZ_qudnZ2d@supernews.com...
>> A. K. <akk@nospam.org> wrote:
>> > On 18.12.2012 22:21, Elizabeth D. Rather wrote:
>> >>  Embedded applications often don't include a programming
>> >> capability, but the standard is for a development system, and
>> >> that is what the "Foreword" is for.
>> >
>> > The title sheet of the standard document explicitly says
>> > PROGRAMMING LANGUAGES -- FORTH
>> > and not
>> > DEVELOPMENT SYSTEMS -- FORTH
>> >
>> > So it's about a LANGUAGE, it's syntax, semantics and all.
>> > A Forth development SYSTEM is just a classic incarnation plus
>> > tools, just as Webster's Dictionary isn't English.
>> >
>> > To repeat, IMO a good foreward should mention this
>> > distinction.
>>
>> This distinction makes no sense for Forth.
> ...
> 
>> It might make sense for C,
>> but not Forth, because Forth is different.
> 
> It's not that different, especially when it comes to other
> interpreted languages, like BASIC or LOGO, etc.
> 
>>  It's interactive.
> 
> So are most BASICs.
> 
>> It gives you all the tools you need to run programs
>> without invoking any external commands.
> 
> So do most BASICs.

So the same reasoning applies.

> I.e., A.K. appears to be correct to me.

That does not follow.

Andrew.

[toc] | [prev] | [next] | [standalone]

#18077

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:vPydnd-kvNtmVE3NnZ2dnUVZ_q6dnZ2d@supernews.com...
...

> The problem is, that there is *no* technical distinction
> between system and program in Forth! That is one of its
> strengths, actually.
>

Non-separation of the OS and applications is usually considered to
be an attack vector.  Strong separation of the two is what secure
OSes implement.  I.e., the access to OS components and their
powerful features allows malicious intent to be realized.

> All of the I/O, compiler tools, and other building blocks
> are available to programmers to use in their applications,
> and many do.
>

That's called a security breach in waiting.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#18078

On Dec 18, 4:24 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Elizabeth D. Rather" <erat...@forth.com> wrote in messagenews:vPydnd-kvNtmVE3NnZ2dnUVZ_q6dnZ2d@supernews.com...
> ...
>
> > The problem is, that there is *no* technical distinction
> > between system and program in Forth! That is one of its
> > strengths, actually.
>
> Non-separation of the OS and applications is usually considered to
> be an attack vector.  Strong separation of the two is what secure
> OSes implement.  I.e., the access to OS components and their
> powerful features allows malicious intent to be realized.

I think you've misunderstood both Elizabeth and the meaning of system
and program in section 5 of the standards doc.

>
> > All of the I/O, compiler tools, and other building blocks
> > are available to programmers to use in their applications,
> > and many do.
>
> That's called a security breach in waiting.

A Forth system supports Forth programs; those programs have access to
the Forth system. This does not mean that the Forth system is
necessarily an OS; often it will not be, but will be hosted on an OS,
and subject to its security. For those Forth systems that provide an
OS, then an attack vector requires a code injection point (either
source or executable); if there is none, then the system can't be
compromised. Many don't have such a facility, since they are only
programmable by cross compilation.

>
> Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#18158

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:06bfc26f-3df4-4f36-be24-7451099bee0f@i7g2000pbf.googlegroups.com...
> On Dec 18, 4:24 pm, "Rod Pemberton"
<do_not_h...@notemailnotz.cnm>
> wrote:
> > "Elizabeth D. Rather" <erat...@forth.com> wrote in message
...

> > > The problem is, that there is *no* technical distinction
> > > between system and program in Forth! That is one of its
> > > strengths, actually.
> >
> > Non-separation of the OS and applications is usually
> > considered to be an attack vector. Strong separation of
> > the two is what secure OSes implement. I.e., the access
> > to OS components and their powerful features allows
> > malicious intent to be realized.
>
> I think you've misunderstood both Elizabeth and the meaning
> of system and program in section 5 of the standards doc.
...

> > > All of the I/O, compiler tools, and other building blocks
> > > are available to programmers to use in their applications,
> > > and many do.
> >
> > That's called a security breach in waiting.
>
> A Forth system supports Forth programs; those programs
> have access to the Forth system. This does not mean that the
> Forth system is necessarily an OS; often it will not be, but
> will be hosted on an OS, and subject to its security. For those
> Forth systems that provide an OS, then an attack vector requires
> a code injection point (either source or executable); if there
> is none, then the system can't be compromised. Many don't
> have such a facility, since they are only programmable by
> cross compilation.

You're assuming that the Forth system itself is not the inherent
weakness which allows the security breach to occur.  Even if a
Forth system is hosted, that system must do what is required to be
a Forth system or a Forth program won't work.  In order to do that
on a hosted OS that is secure, it can mean that the Forth
implementor for that system chose to allow dangerous features or
bypass some of the host OS security in order to implement Forth.
E.g., interpreted Forth allows manipulation of the return stack
which allows jumping or returning to any address, i.e., "code
injection point".  Forth allows directly reading and writing to
memory locations via @ fetch and ! store or C@ c-fetch and C!
c-store.  Either fetch and store with the ability to adjust return
stack items is sufficient to create a "code injection point", but
there are other weaknesses.  Forth's typically use BRANCH and
0BRANCH and other words which have empty addresses or empty
offsets that are patched in.  These too can be used to allow a
"code injection point" too.  Forth has , comma and COMPILE, which
allow similar constructions but in the dictionary.  Etc, etc, etc,
ad infinitum, ad nauseum.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#18181

On Dec 20, 11:21 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:06bfc26f-3df4-4f36-be24-7451099bee0f@i7g2000pbf.googlegroups.com...> On Dec 18, 4:24 pm, "Rod Pemberton"
>
> <do_not_h...@notemailnotz.cnm>> wrote:
> > > "Elizabeth D. Rather" <erat...@forth.com> wrote in message
>
> ...
>
> > > > The problem is, that there is *no* technical distinction
> > > > between system and program in Forth! That is one of its
> > > > strengths, actually.
>
> > > Non-separation of the OS and applications is usually
> > > considered to be an attack vector. Strong separation of
> > > the two is what secure OSes implement. I.e., the access
> > > to OS components and their powerful features allows
> > > malicious intent to be realized.
>
> > I think you've misunderstood both Elizabeth and the meaning
> > of system and program in section 5 of the standards doc.
>
> ...
>
> > > > All of the I/O, compiler tools, and other building blocks
> > > > are available to programmers to use in their applications,
> > > > and many do.
>
> > > That's called a security breach in waiting.
>
> > A Forth system supports Forth programs; those programs
> > have access to the Forth system. This does not mean that the
> > Forth system is necessarily an OS; often it will not be, but
> > will be hosted on an OS, and subject to its security. For those
> > Forth systems that provide an OS, then an attack vector requires
> > a code injection point (either source or executable); if there
> > is none, then the system can't be compromised. Many don't
> > have such a facility, since they are only programmable by
> > cross compilation.
>
> You're assuming that the Forth system itself is not the inherent
> weakness which allows the security breach to occur.  Even if a
> Forth system is hosted, that system must do what is required to be
> a Forth system or a Forth program won't work.  In order to do that
> on a hosted OS that is secure, it can mean that the Forth
> implementor for that system chose to allow dangerous features or
> bypass some of the host OS security in order to implement Forth.
> E.g., interpreted Forth allows manipulation of the return stack
> which allows jumping or returning to any address, i.e., "code
> injection point". Forth allows directly reading and writing to
> memory locations via @ fetch and ! store or C@ c-fetch and C!
> c-store.  Either fetch and store with the ability to adjust return
> stack items is sufficient to create a "code injection point", but
> there are other weaknesses.  Forth's typically use BRANCH and
> 0BRANCH and other words which have empty addresses or empty
> offsets that are patched in.  These too can be used to allow a
> "code injection point" too.  Forth has , comma and COMPILE, which
> allow similar constructions but in the dictionary.  Etc, etc, etc,
> ad infinitum, ad nauseum.
>
> Rod Pemberton

You're very mistaken. The same can be done in C and languages that
support pointers. They can do what you claim is a risky activity in
Forth if the OS is broken; Forth is no more able than any other
language (at least those that aren't sandboxed by design, and even
some of them are broken qv Java).

No OS I know of any quality (Linux, Windows, BSD, Solaris, OSX,
various mainframe OSes, some very old and no longer extant OSes on
DEC, Burroughs etc, microkernel systems like Mach and Minix) permits
userland activities to write into, branch to or otherwise modify
system areas without correct permissions or the availability of an
outright bug. C based OSes were notorious for allowing such activities
by allowing viruses to exploit buffer vulnerabilities, caused in the
main by badly written C code.

Anyhow, Elizabeth was talking about Forth systems and programs, not
operating systems. We have drifted off the subject.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web