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

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

Would ?EXIT work in all ANS-Forth systems?

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

Contents

  Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:21 -0700
    Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-10 16:39 +0100
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:46 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:04 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:22 -0500
        Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 10:35 +0100
          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 05:08 -0500
            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-11 03:51 -0700
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 07:02 -0500
              Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-13 11:55 -0400
          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:32 -0500
            Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 11:56 -0500
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 12:20 -0500
                Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 12:31 -0500
                  Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 15:50 -0500
    Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:49 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 12:04 -0700
    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:08 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:13 +0100
        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:48 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:59 +0100
    Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:20 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-12 17:01 -0700
        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-12 22:18 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-13 03:09 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-13 21:07 +1000
          Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:20 +0000
            Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-14 11:59 +1000
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 09:21 -0500
                Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 10:43 -0700
                  Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 18:35 -0500
                    Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:11 +0200
                      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:35 -0500
                        Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 03:54 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? mhx@iae.nl - 2017-05-15 04:07 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 06:23 -0500
                            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 06:53 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:18 -0500
                    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 22:44 -0700
                      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:16 -0500
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:00 -0700
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:43 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 05:08 -0500
                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:11 +0000
                            Re: Would ?EXIT work in all ANS-Forth systems? NN <november.nihal@gmail.com> - 2017-05-17 05:24 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 07:35 -0500
                                Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 14:59 +0100
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 13:30 +0000
                  Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-15 11:09 +1000
                    Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-14 21:17 -0700
                    Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:13 +0200
                      Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-16 10:24 +1000
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 01:13 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:26 +0000
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-17 01:58 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:45 +0000
                                Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 12:04 -0700
                                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 10:02 +0000
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 07:46 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 13:53 +0000
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 10:14 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 10:16 -0500
                                        Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 08:59 -0700
                                          Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 11:27 -0500
                                            Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 10:19 -0700
                                              Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-26 20:20 +0200
                                                Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 21:38 -0700
                                              Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:06 -0500
                                                Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:00 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 17:06 +0000
                              Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 01:15 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 14:17 +0000
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 17:40 +0000
                          Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-24 15:46 +1000
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 11:51 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 20:38 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:03 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:09 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-26 21:56 +1000
                                  Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-26 13:30 +0100
                                    Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 15:04 +1000
                                      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-27 17:33 +0100
                                        Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-29 12:17 +1000
                                  Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 00:33 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 14:53 +1000
                                  READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-27 21:28 +1000
                                    Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 13:11 +0000
                                      Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-29 13:47 +1000
                                    Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 09:44 +0200
                                      Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 13:41 +0000
                                        Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 19:59 +0200
                        Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 09:42 +0100
                          Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 09:53 +0100
                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 04:53 -0500
                              Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-16 12:32 +0200
                              Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 12:35 +0100
                                Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:48 -0500
                                  Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 18:23 +0100
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 04:33 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 12:29 +0100
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 10:28 +0000
                                Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:43 -0500
                                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 16:34 +0000
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 12:41 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:14 +0000
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 03:05 -0500
                                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 16:33 +0000
                                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 12:43 -0500
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:01 -0500
                                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 15:41 +0000
                                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:58 -0500
                                            Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-18 22:57 +0100
                            Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-17 00:32 +1000
                              Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 15:53 +0100
                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 05:29 +0000
                    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 23:00 -0700
                  Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-17 12:27 -0400
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:16 +0000
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:55 +0000
          Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:25 +0000
            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-13 07:49 -0700
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:59 +0000
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
        Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:19 +0000
    Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-14 23:23 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-15 00:10 -0700
        Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 09:35 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-15 00:54 -0700
        Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 08:47 +0000
          Re: Return-address manipulation (was: Would ?EXIT ...) stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:53 +0000
            Re: Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 13:03 +0000
              Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:06 -0700
                Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:14 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-14 21:58 -1000
        Re: Would ?EXIT work in all ANS-Forth systems? stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:23 +0000

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#58987 — Would ?EXIT work in all ANS-Forth systems?

: ?exit ( flag -- )  if 2r> 2drop then ;

I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.

[toc] | [next] | [standalone]

#58989

On 5/10/2017 16:21, lehs wrote:
> : ?exit ( flag -- )  if 2r> 2drop then ;
> 
> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
> 

Intel are introducing Control Flow Enforcement Technology 
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf 
that will kill return stack tricks like this. The OS folks at Microsoft 
see this as a great way to stop at the hardware level a whole 
significant class of stealth code.

It may even kill CATCH and THROW on hosted systems, since the "standard" 
way of doing THROW usually subverts the usual CALL/RET pairs by 
returning directly to the CATCH.

-- 
Alex

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

#58990

0kay, thanks! It did feel risky.

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

#58994

Alex <alex@rivadpm.com> writes:
>Intel are introducing Control Flow Enforcement Technology 
>https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf 
>that will kill return stack tricks like this. The OS folks at Microsoft 
>see this as a great way to stop at the hardware level a whole 
>significant class of stealth code.

The issue they are trying to prevent is return-oriented programming
(where the attacker implements a kind of direct-threaded code based on
code fragments ("gadgets"), each of which ends in a return (which
functions as NEXT; other indirect branches are also possible).  So
they want to ensure that returns only return to the caller, in
compliance with the original caller.

>It may even kill CATCH and THROW on hosted systems, since the "standard" 
>way of doing THROW usually subverts the usual CALL/RET pairs by 
>returning directly to the CATCH.

Lots of programming languages have features like THROW.  They cannot
kill that.  So they have "shadow stack management instructions" in
chapter 6 of the document to adjust the shadow stack to whatever is
necessary for THROW, return address tricks, whatever.  For Forth it
will probably be necessary to make the return address tricks more
explicit, however.

As for killing stuff, this is an optional feature that has to be
enabled.  Programs that don't have it enabled will work just as
before.  The issue is whether OSs and security software will allow
that such programs will be started.  I think the screw will be
tightened slowly.  E.g., at some point the user will get a warning and
will have to agree when first starting a program without that feature.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#59066

Alex <alex@rivadpm.com> wrote:

> On 5/10/2017 16:21, lehs wrote:
>> : ?exit ( flag -- )  if 2r> 2drop then ;
>> 
>> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
> 
> Intel are introducing Control Flow Enforcement Technology
> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
> that will kill return stack tricks like this. The OS folks at
> Microsoft see this as a great way to stop at the hardware level a
> whole significant class of stealth code.
> 
> It may even kill CATCH and THROW on hosted systems, since the
> "standard" way of doing THROW usually subverts the usual CALL/RET
> pairs by returning directly to the CATCH.

There are enough shadow stack management instructions to cope with
this, I think.  Otherwise, Intel's proposal is dead in the water
anyway.

Andrew.

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

#59068

On 5/11/2017 10:22, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
> 
>> On 5/10/2017 16:21, lehs wrote:
>>> : ?exit ( flag -- )  if 2r> 2drop then ;
>>>
>>> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
>>
>> Intel are introducing Control Flow Enforcement Technology
>> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
>> that will kill return stack tricks like this. The OS folks at
>> Microsoft see this as a great way to stop at the hardware level a
>> whole significant class of stealth code.
>>
>> It may even kill CATCH and THROW on hosted systems, since the
>> "standard" way of doing THROW usually subverts the usual CALL/RET
>> pairs by returning directly to the CATCH.
> 
> There are enough shadow stack management instructions to cope with
> this, I think.  Otherwise, Intel's proposal is dead in the water
> anyway.
> 
> Andrew.
> 

It's been criticized for not really doing what it sets out to do.

<quote>
Finally, as already discovered by past implementors ([P10] [P11] [P12] 
[P13]), shadow stacks cannot be used through compiler modifications 
only. Each OS has their own exceptional cases that need special 
handling. On Linux and similar OSes, these exceptional cases include the 
setjmp/longjmp/makecontext/setcontext set of functions which can violate 
the assumption that a function will return to its call site. It also 
includes the default glibc behavior of lazy binding (done for 
performance reasons) as well as C++ exceptions and asynchronous signal 
handling.

from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
</quote>

The lazy binding piece is interesting; that's the same technique I use 
in WF32 for DLL calls, and I've played with it for late object/message 
binding in Win32forth previously. I can't quite work out how the CET 
shadow stack management instructions proposed would enable what appears 
to be a common technique.

-- 
Alex

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

#59070

Alex <alex@rivadpm.com> wrote:
> On 5/11/2017 10:22, Andrew Haley wrote:
>> Alex <alex@rivadpm.com> wrote:
>> 
>>> On 5/10/2017 16:21, lehs wrote:
>>>> : ?exit ( flag -- )  if 2r> 2drop then ;
>>>>
>>>> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
>>>
>>> Intel are introducing Control Flow Enforcement Technology
>>> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
>>> that will kill return stack tricks like this. The OS folks at
>>> Microsoft see this as a great way to stop at the hardware level a
>>> whole significant class of stealth code.
>>>
>>> It may even kill CATCH and THROW on hosted systems, since the
>>> "standard" way of doing THROW usually subverts the usual CALL/RET
>>> pairs by returning directly to the CATCH.
>> 
>> There are enough shadow stack management instructions to cope with
>> this, I think.  Otherwise, Intel's proposal is dead in the water
>> anyway.
> 
> It's been criticized for not really doing what it sets out to do.
> 
> <quote>
> Finally, as already discovered by past implementors ([P10] [P11] [P12] 
> [P13]), shadow stacks cannot be used through compiler modifications 
> only. Each OS has their own exceptional cases that need special 
> handling. On Linux and similar OSes, these exceptional cases include the 
> setjmp/longjmp/makecontext/setcontext set of functions which can violate 
> the assumption that a function will return to its call site.

These should be handled by the compiler, which is of inlining them and
including the appropriate instructions. 

> It also includes the default glibc behavior of lazy binding (done
> for performance reasons) as well as C++ exceptions and asynchronous
> signal handling.
> 
> from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
> </quote>

That's a bit self serving.

> The lazy binding piece is interesting; that's the same technique I
> use in WF32 for DLL calls, and I've played with it for late
> object/message binding in Win32forth previously. I can't quite work
> out how the CET shadow stack management instructions proposed would
> enable what appears to be a common technique.

And I can't quite tell (from a cursory inspection) what the
interaction with lazy binding would be.

Andrew.

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

#59071

On Thursday, May 11, 2017 at 5:08:31 AM UTC-5, Andrew Haley wrote:
> > from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
> > </quote>
> 
> That's a bit self serving.

I prefer to evaluate policies by asking people that will not be
affected in any way by them. These people are the most likely to lack
any kind of bias in their evaluation.

They're also the most likely to lack any kind of thought in their
evaluation. An 'informed' opinion will be a parrot of whatever media
they follow. But y'know, if the policy doesn't affect *me* either, I
can still feel like an intellectual by fighting the good fight against
bias :-)

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

#59076

Julian Fondren <julian.fondren@gmail.com> wrote:
> On Thursday, May 11, 2017 at 5:08:31 AM UTC-5, Andrew Haley wrote:
>> > from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
>> > </quote>
>> 
>> That's a bit self serving.
> 
> I prefer to evaluate policies by asking people that will not be
> affected in any way by them. These people are the most likely to lack
> any kind of bias in their evaluation.

Or care, unfortunately.

> They're also the most likely to lack any kind of thought in their
> evaluation. An 'informed' opinion will be a parrot of whatever media
> they follow. But y'know, if the policy doesn't affect *me* either, I
> can still feel like an intellectual by fighting the good fight
> against bias :-)

Indeed.  :-)

Andrew.

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

#59179

On 5/11/2017 6:51 AM, Julian Fondren wrote:
> On Thursday, May 11, 2017 at 5:08:31 AM UTC-5, Andrew Haley wrote:
>>> from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
>>> </quote>
>>
>> That's a bit self serving.
>
> I prefer to evaluate policies by asking people that will not be
> affected in any way by them. These people are the most likely to lack
> any kind of bias in their evaluation.
>
> They're also the most likely to lack any kind of thought in their
> evaluation. An 'informed' opinion will be a parrot of whatever media
> they follow. But y'know, if the policy doesn't affect *me* either, I
> can still feel like an intellectual by fighting the good fight against
> bias :-)

Even if someone has no stake in the outcome of an issue, they can have 
bias.

https://en.wikipedia.org/wiki/Bias#Cognitive_biases

A common one which isn't specifically mentioned is a preference for 
something the person is already using or has bought.  Invariably they 
will tell you how great it is working for them.

-- 

Rick C

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

#59310

Alex <alex@rivadpm.com> wrote:
> 
> <quote>
> Finally, as already discovered by past implementors ([P10] [P11] [P12] 
> [P13]), shadow stacks cannot be used through compiler modifications 
> only. Each OS has their own exceptional cases that need special 
> handling. On Linux and similar OSes, these exceptional cases include the 
> setjmp/longjmp/makecontext/setcontext set of functions which can violate 
> the assumption that a function will return to its call site. It also 
> includes the default glibc behavior of lazy binding (done for 
> performance reasons) as well as C++ exceptions and asynchronous signal 
> handling.
> 
> from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
> </quote>

The more I think about this, the more it seems to be a shame that the
IBM System/360 won and the B5500 and its successors lost.  On those
machines, the kind of attack we're talking about can't even be
expressed.

Andrew.

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

#59315

On 5/15/2017 9:32 AM, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
>>
>> <quote>
>> Finally, as already discovered by past implementors ([P10] [P11] [P12]
>> [P13]), shadow stacks cannot be used through compiler modifications
>> only. Each OS has their own exceptional cases that need special
>> handling. On Linux and similar OSes, these exceptional cases include the
>> setjmp/longjmp/makecontext/setcontext set of functions which can violate
>> the assumption that a function will return to its call site. It also
>> includes the default glibc behavior of lazy binding (done for
>> performance reasons) as well as C++ exceptions and asynchronous signal
>> handling.
>>
>> from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
>> </quote>
> 
> The more I think about this, the more it seems to be a shame that the
> IBM System/360 won and the B5500 and its successors lost.  On those
> machines, the kind of attack we're talking about can't even be
> expressed.
> 
> Andrew.
> 
The B5500 had several flaws chief among them was a single stack, it is 
considered 1st generation stack machine, the 2nd generation stack 
machines fixed those issues but it was too late marketing wise. In 1972 
I designed and built my own CPU, it took a lot of ideas from the B5500 
although at the time I had no clue about Forth.

2nd generation is mostly what what one seen with the current batch of 
Forth chips. There is an enhanced 3rd generation stack machine that 
includes stack frame registers and several Index registers those will 
not only run Forth Well but also many Algol family languages rather well.

-- 
Cecil - k5nwa

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

#59317

Cecil Bayona <cbayona@cbayona.com> wrote:
> On 5/15/2017 9:32 AM, Andrew Haley wrote:
>> Alex <alex@rivadpm.com> wrote:
>>>
>>> <quote>
>>> Finally, as already discovered by past implementors ([P10] [P11] [P12]
>>> [P13]), shadow stacks cannot be used through compiler modifications
>>> only. Each OS has their own exceptional cases that need special
>>> handling. On Linux and similar OSes, these exceptional cases include the
>>> setjmp/longjmp/makecontext/setcontext set of functions which can violate
>>> the assumption that a function will return to its call site. It also
>>> includes the default glibc behavior of lazy binding (done for
>>> performance reasons) as well as C++ exceptions and asynchronous signal
>>> handling.
>>>
>>> from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
>>> </quote>
>> 
>> The more I think about this, the more it seems to be a shame that the
>> IBM System/360 won and the B5500 and its successors lost.  On those
>> machines, the kind of attack we're talking about can't even be
>> expressed.
>
> The B5500 had several flaws chief among them was a single stack, it
> is considered 1st generation stack machine, the 2nd generation stack
> machines fixed those issues but it was too late marketing wise. In
> 1972 I designed and built my own CPU, it took a lot of ideas from
> the B5500 although at the time I had no clue about Forth.

OK, but the stackiness of the B5500 isn't really relevant to this
question, which is that of buffer overruns and other mistakes
overwriting return addresses.  What is relevant AIUI are the Burroughs
Mark Stack Control Words and Return Control Word which are maintained
by the hardware.  There's no way that a program can overwrite them, so
the type of failure we're discussing isn't possible.

Andrew.

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

#59318

On 5/15/2017 12:20 PM, Andrew Haley wrote:
> Cecil Bayona <cbayona@cbayona.com> wrote:
>> On 5/15/2017 9:32 AM, Andrew Haley wrote:
>>> Alex <alex@rivadpm.com> wrote:
>>>>
>>>> <quote>
>>>> Finally, as already discovered by past implementors ([P10] [P11] [P12]
>>>> [P13]), shadow stacks cannot be used through compiler modifications
>>>> only. Each OS has their own exceptional cases that need special
>>>> handling. On Linux and similar OSes, these exceptional cases include the
>>>> setjmp/longjmp/makecontext/setcontext set of functions which can violate
>>>> the assumption that a function will return to its call site. It also
>>>> includes the default glibc behavior of lazy binding (done for
>>>> performance reasons) as well as C++ exceptions and asynchronous signal
>>>> handling.
>>>>
>>>> from https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
>>>> </quote>
>>>
>>> The more I think about this, the more it seems to be a shame that the
>>> IBM System/360 won and the B5500 and its successors lost.  On those
>>> machines, the kind of attack we're talking about can't even be
>>> expressed.
>>
>> The B5500 had several flaws chief among them was a single stack, it
>> is considered 1st generation stack machine, the 2nd generation stack
>> machines fixed those issues but it was too late marketing wise. In
>> 1972 I designed and built my own CPU, it took a lot of ideas from
>> the B5500 although at the time I had no clue about Forth.
> 
> OK, but the stackiness of the B5500 isn't really relevant to this
> question, which is that of buffer overruns and other mistakes
> overwriting return addresses.  What is relevant AIUI are the Burroughs
> Mark Stack Control Words and Return Control Word which are maintained
> by the hardware.  There's no way that a program can overwrite them, so
> the type of failure we're discussing isn't possible.
> 
> Andrew.
> 
Just a comment on why it failed, relax.

-- 
Cecil - k5nwa

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

#59331

Cecil Bayona <cbayona@cbayona.com> wrote:
> On 5/15/2017 12:20 PM, Andrew Haley wrote:
>> Cecil Bayona <cbayona@cbayona.com> wrote:
>>> On 5/15/2017 9:32 AM, Andrew Haley wrote:

>>>> The more I think about this, the more it seems to be a shame that the
>>>> IBM System/360 won and the B5500 and its successors lost.  On those
>>>> machines, the kind of attack we're talking about can't even be
>>>> expressed.
>>>
>>> The B5500 had several flaws chief among them was a single stack,
>>> it is considered 1st generation stack machine, the 2nd generation
>>> stack machines fixed those issues but it was too late marketing
>>> wise. In 1972 I designed and built my own CPU, it took a lot of
>>> ideas from the B5500 although at the time I had no clue about
>>> Forth.
>> 
>> OK, but the stackiness of the B5500 isn't really relevant to this
>> question, which is that of buffer overruns and other mistakes
>> overwriting return addresses.  What is relevant AIUI are the
>> Burroughs Mark Stack Control Words and Return Control Word which
>> are maintained by the hardware.  There's no way that a program can
>> overwrite them, so the type of failure we're discussing isn't
>> possible.
>> 
> Just a comment on why it failed, relax.

Relax?  That's a very odd thing to say.

But I take your point about Burroughs.  As I understand it, the main
disadvantage Burroughs had was that it was relatively inefficient
running nasty old FORTRAN programs with common blocks and what have
you.  Also, there was no direct support for multi-dimensional arrays
and global statically-allocated data (much loved by COBOL) was
relatively ineffieicient.  Oh, and no paging, but I'm not entirely
sure that was really a disadvantage,

Andrew.

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

#58995

lehs <skydda.barnen@gmail.com> writes:
>: ?exit ( flag -- )  if 2r> 2drop then ;
>
>I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.

Better use

: ?exit postpone if postpone exit postpone then ; immediate

This is standard code, while the code you posted works only on systems
with two-cell return addresses (i.e., few).

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#59005

Den onsdag 10 maj 2017 kl. 18:52:07 UTC+2 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >: ?exit ( flag -- )  if 2r> 2drop then ;
> >
> >I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
> 
> Better use
> 
> : ?exit postpone if postpone exit postpone then ; immediate
> 
> This is standard code, while the code you posted works only on systems
> with two-cell return addresses (i.e., few).
> 
> - 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: http://www.forth200x.org/forth200x.html
>    EuroForth 2017: http://www.euroforth.org/ef17/

Thanks, much better! I should have been able to figure that out... 

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

#59059

On Wednesday, May 10, 2017 at 6:21:07 PM UTC+3, lehs wrote:
> : ?exit ( flag -- )  if 2r> 2drop then ;
> 
> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.

If you have something:
: callee .. ?EXIT ... ;
: caller ... callee .. ;

If taken, ?EXIT will escape from both "callee" and "caller".

If want some arbitrary escape with preservation(and previously designed :) of data-stack effect, can take a look at  http://theforth.net/package/callec

--
Have a nice day,
hum9

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

#59060

On 5/11/2017 09:08, humptydumpty wrote:
> On Wednesday, May 10, 2017 at 6:21:07 PM UTC+3, lehs wrote:
>> : ?exit ( flag -- )  if 2r> 2drop then ;
>>
>> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
> 
> If you have something:
> : callee .. ?EXIT ... ;
> : caller ... callee .. ;
> 
> If taken, ?EXIT will escape from both "callee" and "caller".
> 
> If want some arbitrary escape with preservation(and previously designed :) of data-stack effect, can take a look at  http://theforth.net/package/callec
> 
> --
> Have a nice day,
> hum9
> 

Or use CATCH/THROW.

-- 
Alex

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

#59063

On Thursday, May 11, 2017 at 11:13:39 AM UTC+3, Alex wrote:
> On 5/11/2017 09:08, humptydumpty wrote:
> > On Wednesday, May 10, 2017 at 6:21:07 PM UTC+3, lehs wrote:
> >> : ?exit ( flag -- )  if 2r> 2drop then ;
> >>
> >> I'm doing a kind of filtering word and want to replace  IF EXIT THEN  with  ?EXIT if this works.
> > 
> > If you have something:
> > : callee .. ?EXIT ... ;
> > : caller ... callee .. ;
> > 
> > If taken, ?EXIT will escape from both "callee" and "caller".
> > 
> > If want some arbitrary escape with preservation(and previously designed :) of data-stack effect, can take a look at  http://theforth.net/package/callec
> > 
> > --
> > Have a nice day,
> > hum9
> > 
> 
> Or use CATCH/THROW.
> 
> -- 
> Alex

CATCH/THROW will not preserve data-stack.  That could be
solved by saving data-stack into variables or return stack.

"Call/ec" preserve data-stack as in direct return-stack escaping. Also is more flexible, using an XT to escape.
That XT could be substituted, or be an XT for inspection, etc.

--
Have a nice day,
hum9

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

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

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

csiph-web