According to Anne & Lynn Wheeler <lynn@garlic.com>:
>TSS/360 (official virtual memory operating system for 360/67) had solved
>that problem by moving the RLD equivalents to a separate system table
>... and program invokation just required prebuilding that table ... and
>then mapping virtual memory to program image on disk (w/o preloading)
>and invoking the program. This also had the advantage in that several
>application address spaces could have concurrent shared image of the
>same program ... concurrently (even located at different virtual
>addresses, in different address spaces).

Sort of. On TSS there were CSECTs which were position-independent read
only reentrant code and PSECTs (prototype sections) which were
writable everything else. Each routine had one of each, the assembler
and loader and I guess linker had V type address constants for the
CSECT and R type adcons for the PSECT, and the calling sequence was
more complicated than the OS one, with the caller storing the callee's
R pointer in the save area for the callee to retrieve so it could find
its data.

It worked but it wasn't fast and I expect it made the paging problems even worse.

These days Unix and linux systems do more or less the same thing but they limit
the overhead by combining all of the writable data for an entire library into
one place and loading it immediately after the code so intructions can use
relative offsets to get to the data.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
> The IBMSJ article on the 360 architecture says that the point of base+displacement
> addressing was to made the addresses in the instructions small enough to let code
> fit on small systems (remember that DOS originally ran in 16K) while enabling linear
> addressing in large systems. I think they also wrongly believed that forcing all
> addresses to use base registers would make hardware relocation unnecessary, which was
> of course completely wrong.
>
> I gather that the code in APL\360 was sufficiently disciplined that it
> could swap out a user's data block and swap it back in somewhere else
> and fix up the data base register and it would work, but that was
> quite unusual.

APL\360 was all interpreted ... so didn't actually execute ... it was
code in the fixed supervisor that executed. Typical APL/360 had two
16kbyte swap regions and could swap out and swap back into either swap
regions ... and then apl\360 just had register(s) that pointed to the
specific workspace region.

Note APL\360 did no storage allocation on every assignment ... and when
it exhaused available storage (in 16kbyte workspace region), it would
garbage collection and condense all used space to contiguous area. When
science center ported it to CP67/CMS for CMS\APL wih larrge virtual
memory (demand paged) workspaces ... it would cause enormous amount of
page thrashing ... guarenteed to repeatedly & quickly touch every
available virtual memory page ... and then garbage collect and start
again ... even relatively small program with lots of assignments would
repeatedly traverse all available pages in the virtual address space.
This had to be completely reworked for demand page large virtual memory
workspaces.

--
virtualization experience starting Jan1968, online at home since Mar1970

this has discussion of assembler generating RLD (ESD, TXT, etc) cards
http://www.bitsavers.org/pdf/ibm/370/asm/SC26-3759-1_OS_Assembler_H_Programmers_Guide_Jun72.pdf

this has discussion of linkedit processing RLD (ESD, TXT, etc) card
http://www.bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/GC28-6538-9_OS_Linkage_Editor_and_Loader_Release_21_Jan72.pdf

i.e. before starting execution, link editor fiddles all the information
to force address constants to their "real" (and then later virtual)
address corresponding to the location that it has been loaded

--
virtualization experience starting Jan1968, online at home since Mar1970

John Levine <johnl@taugh.com> writes:
> These days Unix and linux systems do more or less the same thing but they limit
> the overhead by combining all of the writable data for an entire library into
> one place and loading it immediately after the code so intructions can use
> relative offsets to get to the data.

Some of the MIT CTSS people went to the 5th flr and Project MAC to do
MULTICS and others went to science center on the 4th flr and did
cp40/cms ... which morphs into cp67/cms when 360/67 standard with
virtual memory becomes available.

When I joined the science center, I figured I could do anything the
multics people were doing, so wrote a page-mapped filesystem for CMS and
provided support for location independent execution (even having r/o
sharing of same executable image at different virtual addresses in
different virtual address spaces).

To actually support R/O shared (segment) location independence (since
the underlying stuff borrowed from os/360 didn't), I had to manually
rewrite application inline code to support sharing and use relative
offsets (rather than RLD processing, which would have also modified
storage violating R/O shared) ... managed to do it for major, high-use
applications ... editors, shell/execs, various other applications and
utilities.

--
virtualization experience starting Jan1968, online at home since Mar1970

On Thursday, July 8, 2021 at 9:28:29 PM UTC-6, John Levine wrote:
> I think they also wrongly believed that forcing all
> addresses to use base registers would make hardware relocation unnecessary, which was
> of course completely wrong.

True, but it _did_ make hardware relocation faster, since now only the addresses used
to load the base registers had to be adjusted, not every single address in every instruction.

John Savard

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Thursday, July 8, 2021 at 9:28:29 PM UTC-6, John Levine wrote:
>> I think they also wrongly believed that forcing all
>> addresses to use base registers would make hardware relocation unnecessary, which was
>> of course completely wrong.
>
>True, but it _did_ make hardware relocation faster, since now only the addresses used
>to load the base registers had to be adjusted, not every single address in every instruction.

I presume you mean relocation at program fetch time. I suppose so,
although if you look at the code from Fortran G, it generated an awful
lot of address pointers in memory that had to be relocated.

Later on they realized that relative addresses in branch instructions
are what you want. A 16 bit signed offset, shifted one bit since
instructions have to be halfword aligned, covers 64K in either
direction with no base register and that's a pretty big routine.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

MitchAlsup <MitchAlsup@aol.com> wrote:
> On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
> > In article <8b1baea3-a802-4341...@googlegroups.com>,
> > MitchAlsup <Mitch...@aol.com> wrote:
> > >On Saturday, June 26, 2021 at 10:54:53 AM UTC-5, EricP wrote:
> > >> MitchAlsup wrote:
> > >> > <
> > >> > To show the extent of my disfavor for EXC, in My 66000 one cannot
> > >execute code in a page
> > >> > that is writable !
> > >> That forces JIT'ers and self modifiers to make a trip through
> > >> the OS to change the page protection from RW to RE.
> > ><
> > >No, it requires the JIT to run in a different address mapping than the
> > >application
> > >using the JITted code. Since this transition only costs 12 cycles plus cache
> > >effects, it is well worth while.
> > ><
> > >> Not that it is a bad thing as it does allow the OS to clean up model
> > >> specfic things like caches and prefetch buffers across multiple SMP cores.
> >
> > Can you explain why you're doing this? What does having the JIT modification
> > be in a different address space help in the hardware? I'm not seeing how
> > this really helps, other than to make certain JIT strategies harder.
> <
> Protection::
> The executor of the code cannot modify the code (no write permission).
> The JIT is not in the address space of the "application"
> The "application" cannot modify the JITer or even see it
> The "application" can only see the ASCII code given to the JIT.
> The "application" can only execute from JIT cache.
> Thus:: JIT smells a lot more like a dynamic library than current.

Hmm, consider language implementation as follows:

- functions posses modifiable metadata, including pointer to
actual code. Currently code directly follows metadata,
but in principle could be allocated in separate area.
- there is separate control stack (used for local variables
and return address) and data stack (mostly used for argument
passing). All arguments are passed on data stack.
Similarly return values are on data stack.
- Given a function f and values v1,...,vn one can create a new
function g which first pushes v1, ...,vn onto data stack
and then calls f. Currently this is accomplished by
creating header + small machine code snippet to do argument pushing,
but could be modifed to have code in separate area.
After such modification it would be possible to create
new function as pure data manipulation (re-using machine
code from other function).
- Given functions f and g one can create new function h which
has effect of calling f first and when f returns calling
g (if f needs arguments it takes them from data stack...).
- there is compiler which at runtime can compile new code

AFAICS, once attacker can modify data area, he has complete
control of the application:
1) He can create new composed function which first calls
compiler to compile his code and then calls it ("apply"
is available as a built-in function)
2) He can modify one of function pointers so that his
function gets called instead of one of functions belonging
to the application

In other words, separating code and data gives really no
extra protection. Do you think that this is bad language?

BTW1: Code can be garbage collected. Garbage collector may
move code, but otherwise keeps code as is. To account
for changed location garbage collector adjusts metadata.

BTW2: I looked at this issue because "security" folks want
to disable "writable and executable" memory. If they
persist it is likely that developement effort will go
into pointless excercise of puting code in separate area,
which will mean more indirection via function pointers,
slightly larger and slower code, but as explaned no
extra security. There was also proposal to switch
to interpreted bytecode. Since from point of view
of CPU bytecode is data, such program is considered
"secure". But overwritng bytecode can have as bad
effect as overwriting machine code, so no real
gain in security.

--
Waldek Hebisch

Quadibloc <jsavard@ecn.ab.ca> wrote:
>
> Out of curiosity, I checked the Principles of Operation of the IBM System/360 to see
> if _it_ had an Execute instruction. It did. But it had limitations which meant that it
> could *not* be used the way the execute instruction on the SDS 930 could be used.
>
> Only bits 8 through 15 of the executed instruction could be modified.

Argument to execute is in memory, so you write instruction first, then
execute it. If you are after saving single instruction, then extra
write defeats the purpose. If you want to interpret arbitrary 360
instructions, it is probably much faster than alternatives. Anyway,
Execute was used by ASSIST to provide "safe" execution of 360 code
in the same address space as assembler. Interpreter first checked
for problematic instructions and after simple mangling passed
most to Execute (the remaing few had to be fully interpreted).

--
Waldek Hebisch

On Thursday, July 29, 2021 at 2:25:01 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> MitchAlsup <Mitch...@aol.com> wrote:
> > On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
> > > In article <8b1baea3-a802-4341...@googlegroups.com>,
> > > MitchAlsup <Mitch...@aol.com> wrote:
> > > >On Saturday, June 26, 2021 at 10:54:53 AM UTC-5, EricP wrote:
> > > >> MitchAlsup wrote:
> > > >> > <
> > > >> > To show the extent of my disfavor for EXC, in My 66000 one cannot
> > > >execute code in a page
> > > >> > that is writable !
> > > >> That forces JIT'ers and self modifiers to make a trip through
> > > >> the OS to change the page protection from RW to RE.
> > > ><
> > > >No, it requires the JIT to run in a different address mapping than the
> > > >application
> > > >using the JITted code. Since this transition only costs 12 cycles plus cache
> > > >effects, it is well worth while.
> > > ><
> > > >> Not that it is a bad thing as it does allow the OS to clean up model
> > > >> specfic things like caches and prefetch buffers across multiple SMP cores.
> > >
> > > Can you explain why you're doing this? What does having the JIT modification
> > > be in a different address space help in the hardware? I'm not seeing how
> > > this really helps, other than to make certain JIT strategies harder.
> > <
> > Protection::
> > The executor of the code cannot modify the code (no write permission).
> > The JIT is not in the address space of the "application"
> > The "application" cannot modify the JITer or even see it
> > The "application" can only see the ASCII code given to the JIT.
> > The "application" can only execute from JIT cache.
> > Thus:: JIT smells a lot more like a dynamic library than current.
>
> Hmm, consider language implementation as follows:
>
> - functions posses modifiable metadata, including pointer to
> actual code. Currently code directly follows metadata,
> but in principle could be allocated in separate area.
> - there is separate control stack (used for local variables
> and return address) and data stack (mostly used for argument
> passing). All arguments are passed on data stack.
> Similarly return values are on data stack.
> - Given a function f and values v1,...,vn one can create a new
> function g which first pushes v1, ...,vn onto data stack
> and then calls f. Currently this is accomplished by
> creating header + small machine code snippet to do argument pushing,
> but could be modifed to have code in separate area.
> After such modification it would be possible to create
> new function as pure data manipulation (re-using machine
> code from other function).
> - Given functions f and g one can create new function h which
> has effect of calling f first and when f returns calling
> g (if f needs arguments it takes them from data stack...).
> - there is compiler which at runtime can compile new code
>
> AFAICS, once attacker can modify data area, he has complete
> control of the application:
> 1) He can create new composed function which first calls
> compiler to compile his code and then calls it ("apply"
> is available as a built-in function)
<
Not in My 66000, it is illegal to have both write and execute
permissions simultaneously in a PTE. So, if you wrote it
you cannot execute it. Someone with higher permissions
can write it, transfer control back to you (context switch)
and then you can execute it.
<
> 2) He can modify one of function pointers so that his
> function gets called instead of one of functions belonging
> to the application
<
Yes, but the function needs to be in Execute only PTE mapping.
>
> In other words, separating code and data gives really no
> extra protection. Do you think that this is bad language?
>
> BTW1: Code can be garbage collected. Garbage collector may
> move code, but otherwise keeps code as is. To account
> for changed location garbage collector adjusts metadata.
>
> BTW2: I looked at this issue because "security" folks want
> to disable "writable and executable" memory.
<
My 66000 makes this a HW detected problem. W+X = fault.
<
< If they
> persist it is likely that developement effort will go
> into pointless excercise of puting code in separate area,
> which will mean more indirection via function pointers,
<
I see no additional pointer indirections.
<
> slightly larger and slower code, but as explaned no
> extra security. There was also proposal to switch
> to interpreted bytecode. Since from point of view
> of CPU bytecode is data, such program is considered
> "secure". But overwritng bytecode can have as bad
> effect as overwriting machine code, so no real
> gain in security.
<
Which is why I don't want anyone without special privileges
to write what can be considered code.
>
> --
> Waldek Hebisch

On Thursday, July 29, 2021 at 1:25:01 PM UTC-6, anti...@math.uni.wroc.pl wrote:

> BTW2: I looked at this issue because "security" folks want
> to disable "writable and executable" memory.

> But overwritng bytecode can have as bad
> effect as overwriting machine code, so no real
> gain in security.

I think you're overlooking an important point here.

Preventing memory that is executable from also being written
does provide a real gain in security *in the usual case* where
people are running programs that have been written in assembler
or compiled to machine language at a previous time.

Of course, the linking loader or whatever reads the program off
the disk and writes it to memory has to be able to write to memory
that will later be marked for execution. But nothing else.

Bytecode, whether it is interpreted or turned into machine instructions
by JIT compilation, does indeed tell the computer to do things.

Let us accept that this case can be considered an _afterthought_;
not allowing machine code to be re-written limits the usual thing
virus writers used to do. Now, if write/execute protections force them
to fiddle with bytecode instead... well, is the fact that people can
break windows a reason not to lock your front door?

Preventing machine code from being written is assumed to prevent
the code from doing "bad things". But what if the code was doing
bad things in the first place? So write/execute protections don't
totally prevent code executing on the computer from doing malicious
stuff; the _application writer_ is also responsible for not doing bad
stuff too.

Thus, clearly, how write/execute protections can still be useful
in a world where there is bytecode and JIT compilation should now
be clear. Just as people who write applications must not put bad
stuff in their programs (and also be vigilant against _supply-chain
attacks_), people who write JavaScript interpreters or engines or
whatever you call them... need to be vigiliant so as to make their
programs *not generate code useful to malicious actors* in response
to any bytecode inputs.

That may not always be easy or even feasible, since if a program
can throw up a screen to communicate with the user, it can make
that screen look like one from the operating system (of course,
it has been done to sandbox a system like that so that all the
screens it puts up have a special border, but so far this tends to
be considered an extreme measure) and in other ways do malicious
things without high privilege.

John Savard

On Thursday, July 29, 2021 at 2:07:58 PM UTC-6, MitchAlsup wrote:

> Which is why I don't want anyone without special privileges
> to write what can be considered code.

Isn't that basically true of any system with write-execute
protection mechanisms?

Programs like JIT interpreters, just like the loader, have to be
identified to the operating system.

However, "can be considered" could include, say, JavaScript
source code. Which was prepared on an editor _running on
another computer_ which may not have a My 66000 processor
installed.

A program written in JavaScript "may be considered" program
code, but the only means of control one would have to prevent
anyone to whom you haven't extended system credentials
from writing it for execution on your system... is basically
to disable JavaScript functionality in any browser running on
your machine.

So if you want fully functional Internet connectivity and security
as well, you need another security mechanism besides saying
"no". You also need to have a sandbox in which untrusted code
*can* be allowed to execute... well, at least until those who have
designed the Internet with which we all must cope come to their
senses.

Security must be something that can be implemented in the real
world, as a utopian dream will benefit no one.

John Savard

Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Thursday, July 29, 2021 at 1:25:01 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
> > BTW2: I looked at this issue because "security" folks want
> > to disable "writable and executable" memory.
>
> > But overwritng bytecode can have as bad
> > effect as overwriting machine code, so no real
> > gain in security.
>
> I think you're overlooking an important point here.
>
> Preventing memory that is executable from also being written
> does provide a real gain in security *in the usual case* where
> people are running programs that have been written in assembler
> or compiled to machine language at a previous time.

I have nothing against making code unwritable _by default_.
However, if program _wants_ writable and executable memory
OS and architecture should not forbid this.
> Thus, clearly, how write/execute protections can still be useful
> in a world where there is bytecode and JIT compilation should now
> be clear. Just as people who write applications must not put bad
> stuff in their programs (and also be vigilant against _supply-chain
> attacks_), people who write JavaScript interpreters or engines or
> whatever you call them... need to be vigiliant so as to make their
> programs *not generate code useful to malicious actors* in response
> to any bytecode inputs.

Runtime compilation is _very_ useful. Due to its general usefulness
it helps attacker too. I have seen Linux system where adminstrator
removed programs like perl because "it is used by rootkits".
If you do not need perl not installing it may gain you maybe
0.00001% extra security, but normally limiting essential
functionality makes no sense: if normal way of doing essential
things is forbidden, then users will find another, possibly
less secure way.
--
Waldek Hebisch

On Thursday, July 29, 2021 at 5:20:16 PM UTC-5, Quadibloc wrote:
> On Thursday, July 29, 2021 at 2:07:58 PM UTC-6, MitchAlsup wrote:
>
> > Which is why I don't want anyone without special privileges
> > to write what can be considered code.
<
> Isn't that basically true of any system with write-execute
> protection mechanisms?
<
It depends. In x86, for example, one can set the NX (no execute) bit in
a PTE but one does not HAVE TO use it like that.
<
In My 66000 if both the W and the X bit are set in a PTE the HW takes a trap
due to the illegal condition. So in order to support both W and X permissions
the SW has to setup a trap handler which ping pongs the permissions back
and forth--leading them to quickly realize there HAS TO BE a better way to do
it.
>
> Programs like JIT interpreters, just like the loader, have to be
> identified to the operating system.
>
> However, "can be considered" could include, say, JavaScript
> source code. Which was prepared on an editor _running on
> another computer_ which may not have a My 66000 processor
> installed.
>
> A program written in JavaScript "may be considered" program
> code, but the only means of control one would have to prevent
> anyone to whom you haven't extended system credentials
> from writing it for execution on your system... is basically
> to disable JavaScript functionality in any browser running on
> your machine.
<
There are over 300 sites on my javascrip controller in Chrome with JS
turned off.
>
> So if you want fully functional Internet connectivity and security
> as well, you need another security mechanism besides saying
> "no". You also need to have a sandbox in which untrusted code
> *can* be allowed to execute... well, at least until those who have
> designed the Internet with which we all must cope come to their
> senses.
<
You can do this efficiently because context switches are only 12 cycles.
You could not do this efficiently on a machine where context switches
are 1000+ cycles.
>
> Security must be something that can be implemented in the real
> world, as a utopian dream will benefit no one.
<
Security must also be something that does not leave all the doors and
window open so that bad actors in the quise of doing something positive
get let in to reek their havoc.
>
> John Savard

On 7/29/2021 4:11 PM, MitchAlsup wrote:

> Security must also be something that does not leave all the doors and
> window open so that bad actors in the quise of doing something positive
> get let in to reek their havoc.

wreak: https://en.wiktionary.org/wiki/wreak

On 7/29/2021 3:12 PM, Quadibloc wrote:
> On Thursday, July 29, 2021 at 1:25:01 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
>> BTW2: I looked at this issue because "security" folks want
>> to disable "writable and executable" memory.
>
>> But overwritng bytecode can have as bad
>> effect as overwriting machine code, so no real
>> gain in security.
>
> I think you're overlooking an important point here.
>
> Preventing memory that is executable from also being written
> does provide a real gain in security *in the usual case* where
> people are running programs that have been written in assembler
> or compiled to machine language at a previous time.
>
> Of course, the linking loader or whatever reads the program off
> the disk and writes it to memory has to be able to write to memory
> that will later be marked for execution. But nothing else.
>
> Bytecode, whether it is interpreted or turned into machine instructions
> by JIT compilation, does indeed tell the computer to do things.
>
> Let us accept that this case can be considered an _afterthought_;
> not allowing machine code to be re-written limits the usual thing
> virus writers used to do. Now, if write/execute protections force them
> to fiddle with bytecode instead... well, is the fact that people can
> break windows a reason not to lock your front door?
>
> Preventing machine code from being written is assumed to prevent
> the code from doing "bad things". But what if the code was doing
> bad things in the first place? So write/execute protections don't
> totally prevent code executing on the computer from doing malicious
> stuff; the _application writer_ is also responsible for not doing bad
> stuff too.
>
> Thus, clearly, how write/execute protections can still be useful
> in a world where there is bytecode and JIT compilation should now
> be clear. Just as people who write applications must not put bad
> stuff in their programs (and also be vigilant against _supply-chain
> attacks_), people who write JavaScript interpreters or engines or
> whatever you call them... need to be vigiliant so as to make their
> programs *not generate code useful to malicious actors* in response
> to any bytecode inputs.
>
> That may not always be easy or even feasible, since if a program
> can throw up a screen to communicate with the user, it can make
> that screen look like one from the operating system (of course,
> it has been done to sandbox a system like that so that all the
> screens it puts up have a special border, but so far this tends to
> be considered an extreme measure) and in other ways do malicious
> things without high privilege.
>
> John Savard
>

Anther advantage is that the I and D caches don't have t be coherent.

On 7/29/2021 3:20 PM, Quadibloc wrote:
> On Thursday, July 29, 2021 at 2:07:58 PM UTC-6, MitchAlsup wrote:
>
>> Which is why I don't want anyone without special privileges
>> to write what can be considered code.
>
> Isn't that basically true of any system with write-execute
> protection mechanisms?
>
> Programs like JIT interpreters, just like the loader, have to be
> identified to the operating system.
>
> However, "can be considered" could include, say, JavaScript
> source code. Which was prepared on an editor _running on
> another computer_ which may not have a My 66000 processor
> installed.
>
> A program written in JavaScript "may be considered" program
> code, but the only means of control one would have to prevent
> anyone to whom you haven't extended system credentials
> from writing it for execution on your system... is basically
> to disable JavaScript functionality in any browser running on
> your machine.

You could do that (and many do), but why is it not a bug in the JS
compiler/interpreter to generate anything that breaks security?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, July 29, 2021 at 7:25:54 PM UTC-5, Stephen Fuld wrote:
> On 7/29/2021 3:20 PM, Quadibloc wrote:
> > On Thursday, July 29, 2021 at 2:07:58 PM UTC-6, MitchAlsup wrote:
> >
> >> Which is why I don't want anyone without special privileges
> >> to write what can be considered code.
> >
> > Isn't that basically true of any system with write-execute
> > protection mechanisms?
> >
> > Programs like JIT interpreters, just like the loader, have to be
> > identified to the operating system.
> >
> > However, "can be considered" could include, say, JavaScript
> > source code. Which was prepared on an editor _running on
> > another computer_ which may not have a My 66000 processor
> > installed.
> >
> > A program written in JavaScript "may be considered" program
> > code, but the only means of control one would have to prevent
> > anyone to whom you haven't extended system credentials
> > from writing it for execution on your system... is basically
> > to disable JavaScript functionality in any browser running on
> > your machine.
> You could do that (and many do), but why is it not a bug in the JS
> compiler/interpreter to generate anything that breaks security?
<
Could be a bug in the JS; for example finding code sequences (because
they are readable) that contain RET instructions and using this as an
ROP attack means.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Thursday, July 29, 2021 at 5:21:27 PM UTC-6, Ivan Godard wrote:
> On 7/29/2021 4:11 PM, MitchAlsup wrote:

> > Security must also be something that does not leave all the doors and
> > window open so that bad actors in the quise of doing something positive
> > get let in to reek their havoc.

> wreak: https://en.wiktionary.org/wiki/wreak

Yes, but I'll assume it was just a typo, and he knew the difference between
a bad smell and working havoc. Even if I myself was recently picky about the
Kogge-Stone adder.

John Savard

On Thursday, July 29, 2021 at 6:25:54 PM UTC-6, Stephen Fuld wrote:
> why is it not a bug in the JS
> compiler/interpreter to generate anything that breaks security?

Indeed, it is a duty for a JavaScript compiler/interpreter to block
the generation or execution of code that violates security; otherwise,
the objection that the existence of things like JavaScript makes
write/execute protections useless would be valid.

However, there are many ways to break security - programs that extract
timing information, for side-channel attacks like Spectre, for example,
have been written in JavaScript, and that sort of activity is quite hard
to detect.

John Savard

MitchAlsup <MitchAlsup@aol.com> wrote:
> On Thursday, July 29, 2021 at 2:25:01 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> > MitchAlsup <Mitch...@aol.com> wrote:
> > > On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
> > > > In article <8b1baea3-a802-4341...@googlegroups.com>,
> > > > MitchAlsup <Mitch...@aol.com> wrote:
> > > > >On Saturday, June 26, 2021 at 10:54:53 AM UTC-5, EricP wrote:
> > > > >> MitchAlsup wrote:
> > > > >> > <
> > > > >> > To show the extent of my disfavor for EXC, in My 66000 one cannot
> > > > >execute code in a page
> > > > >> > that is writable !
> > > > >> That forces JIT'ers and self modifiers to make a trip through
> > > > >> the OS to change the page protection from RW to RE.
> > > > ><
> > > > >No, it requires the JIT to run in a different address mapping than the
> > > > >application
> > > > >using the JITted code. Since this transition only costs 12 cycles plus cache
> > > > >effects, it is well worth while.
> > > > ><
> > > > >> Not that it is a bad thing as it does allow the OS to clean up model
> > > > >> specfic things like caches and prefetch buffers across multiple SMP cores.
> > > >
> > > > Can you explain why you're doing this? What does having the JIT modification
> > > > be in a different address space help in the hardware? I'm not seeing how
> > > > this really helps, other than to make certain JIT strategies harder.
> > > <
> > > Protection::
> > > The executor of the code cannot modify the code (no write permission).
> > > The JIT is not in the address space of the "application"
> > > The "application" cannot modify the JITer or even see it
> > > The "application" can only see the ASCII code given to the JIT.
> > > The "application" can only execute from JIT cache.
> > > Thus:: JIT smells a lot more like a dynamic library than current.
> >
> > Hmm, consider language implementation as follows:
> >
> > - functions posses modifiable metadata, including pointer to
> > actual code. Currently code directly follows metadata,
> > but in principle could be allocated in separate area.
> > - there is separate control stack (used for local variables
> > and return address) and data stack (mostly used for argument
> > passing). All arguments are passed on data stack.
> > Similarly return values are on data stack.
> > - Given a function f and values v1,...,vn one can create a new
> > function g which first pushes v1, ...,vn onto data stack
> > and then calls f. Currently this is accomplished by
> > creating header + small machine code snippet to do argument pushing,
> > but could be modifed to have code in separate area.
> > After such modification it would be possible to create
> > new function as pure data manipulation (re-using machine
> > code from other function).
> > - Given functions f and g one can create new function h which
> > has effect of calling f first and when f returns calling
> > g (if f needs arguments it takes them from data stack...).
> > - there is compiler which at runtime can compile new code
> >
> > AFAICS, once attacker can modify data area, he has complete
> > control of the application:
> > 1) He can create new composed function which first calls
> > compiler to compile his code and then calls it ("apply"
> > is available as a built-in function)
> <
> Not in My 66000, it is illegal to have both write and execute
> permissions simultaneously in a PTE. So, if you wrote it
> you cannot execute it. Someone with higher permissions
> can write it, transfer control back to you (context switch)
> and then you can execute it.

I am not sure if you understand what I wrote. Above language
function consist of metadata + executable code. Metadata
includes function pointer to executable code. Attacker can
do his job by modifying metadata, no need to touch code.
To be more precise, code needed by attacker already exists,
he just needs to feed it with appropriate data.

Maybe you want to say that I can not have runtime compiler?
But you say that I can, just that I need helper process
with extra priviledges.

> <
> > 2) He can modify one of function pointers so that his
> > function gets called instead of one of functions belonging
> > to the application
> <
> Yes, but the function needs to be in Execute only PTE mapping.

Code yes. But meta-data is just data. Each function has header
that looks like

name |tag | pointer to code| other data ...

^
|
Language function pointer point here

Each function call is "memory indirect", on normal architectures
language function pointer is loaded to a register first, than
pointer to code is loaded to another register and finally
there is call via register. Note: executable code is fully
relocatable and contains no memory addresses, all addresses
are in data parts. All that is needed to divert control
flow is to modify data, no need to touch Execute only pages.

If you want to say that attacker has to depend on already
existing code, then this is true. What I am saying that
needed code already exists, so fact that there are Execute
only pages provides _no_ extra protection.

> >
> > In other words, separating code and data gives really no
> > extra protection. Do you think that this is bad language?
> >
> > BTW1: Code can be garbage collected. Garbage collector may
> > move code, but otherwise keeps code as is. To account
> > for changed location garbage collector adjusts metadata.
> >
> > BTW2: I looked at this issue because "security" folks want
> > to disable "writable and executable" memory.
> <
> My 66000 makes this a HW detected problem. W+X = fault.
> <
> < If they
> > persist it is likely that developement effort will go
> > into pointless excercise of puting code in separate area,
> > which will mean more indirection via function pointers,
> <
> I see no additional pointer indirections.

Currently on ARM and x86_64 code takes advantage of fact
that metadata is just befor code and uses PC-relative
addressing. Separate execute-only area means that
must be separate pointers. Most indirection via
function pointers is already in place, but separationg
executable area is likely to require some extra
indirection since existing positional dependencies
are broken.

> > slightly larger and slower code, but as explaned no
> > extra security. There was also proposal to switch
> > to interpreted bytecode. Since from point of view
> > of CPU bytecode is data, such program is considered
> > "secure". But overwritng bytecode can have as bad
> > effect as overwriting machine code, so no real
> > gain in security.
> <
> Which is why I don't want anyone without special privileges
> to write what can be considered code.

But this is loosing battle: Goedel and Turing say that
you can not win: recognizing "what can be considered code"
is uncomputable. Interpreters are widely accepted
and if My 6600 does not support them well, people
will choose another machine. Puting it differently,
you may try to forbid Emacs, you may get away with
forbing Lisp (and you ejected significant obstacles
to high-performace Lisp), but trying to forbid Python
and company is sure fail.

--
Waldek Hebisch

MitchAlsup <MitchAlsup@aol.com> wrote:
> Security must also be something that does not leave all the doors and
> window open so that bad actors in the quise of doing something positive
> get let in to reek their havoc.

AFAICS biggest security problem is due to buffer overflows. I would
expect security concious folks to help in fight with buffer overflows.
That includes support for languages which check or at least
can check all array accesses. ATM I see that you are pushing
everyone to use C, where checking for array accesses at best
is tricky (C++ makes this better, but leaves hole for leagacy
C code).

--
Waldek Hebisch

MitchAlsup <MitchAlsup@aol.com> writes:
>In My 66000 if both the W and the X bit are set in a PTE the HW takes a trap
>due to the illegal condition. So in order to support both W and X permissions
>the SW has to setup a trap handler which ping pongs the permissions back
>and forth--leading them to quickly realize there HAS TO BE a better way to do
>it.

In Gforth we will just take the easy way: disable dynamic native code
generation and revert to plain threaded code. The bottom line is a
certain slowdown (e.g., a factor of 2 for fft on Skylake) and zero
additional security, because Gforth can do everything machine language
can do; most stuff out of the box, but the rest by constructing an
appropriate binary and dynamically loading it.

This restriction of My66000 might be a good fit for locked-down devices
like the iPhone, where you can only run binaries blessed by Apple, and
Apple in general does not bless language interpreters. However, as
the Pegasus spyware demonstrates, even Apple's approach does not
provide security, so the measures above are really about protecting
Apple's app-store monopoly on iOS.

It seems to me that those OSs that want to disable WX can do so
without problems on existing hardware, e.g., by replying with EINVAL
or (your approach) some trap to mmap(... PROT_EXEC|PROT_WRITE ...),
and I guess there are quite a number of people who think that would be
a good idea. But there is obviously enough software that would break,
and while you are probably not alone in thinking that breaking such
software is a good idea, it's not prevalent in Linux and Windows last
time I looked. Baking this restriction into the hardware will just
ensure that nobody will use it for a general-purpose computer.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, July 30, 2021 at 8:16:41 AM UTC-6, Anton Ertl wrote:

> This restriction of My66000 might be a good fit for locked-down devices
> like the iPhone, where you can only run binaries blessed by Apple, and
> Apple in general does not bless language interpreters. However, as
> the Pegasus spyware demonstrates, even Apple's approach does not
> provide security, so the measures above are really about protecting
> Apple's app-store monopoly on iOS.

Yes, Apple seeks to preserve its highly profitable app store monopoly
on iOS. That is first and foremost what the locked-down nature of iOS
is about. I do not disagree with this claim.

However, I do, very strongly, disagree with the claim that the fact that
the... incidental security benefits... of Apple's policies are less than
perfect, as the recent Pegasus debacle shows... is in any way
_evidence_ of the motivation behind Apple's app store policies.

Even if Apple locked down its app store for reasons that were pure
as the driven snow, that would not give it the ability to design a
secure system that determined adversaries with funding and
expertise could not subvert.

John Savard

On 7/30/2021 2:00 AM, Quadibloc wrote:
> On Thursday, July 29, 2021 at 6:25:54 PM UTC-6, Stephen Fuld wrote:
>> why is it not a bug in the JS
>> compiler/interpreter to generate anything that breaks security?
>
> Indeed, it is a duty for a JavaScript compiler/interpreter to block
> the generation or execution of code that violates security; otherwise,
> the objection that the existence of things like JavaScript makes
> write/execute protections useless would be valid.
>
> However, there are many ways to break security - programs that extract
> timing information, for side-channel attacks like Spectre, for example,
> have been written in JavaScript, and that sort of activity is quite hard
> to detect.

Sure. But Specter attacks should be prevented in the hardware, and has
nothing to do with write/execute permissions. My position is that Java
script should be no less secure than any other language program.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Quadibloc <jsavard@ecn.ab.ca> writes:
>Preventing memory that is executable from also being written
>does provide a real gain in security *in the usual case* where
>people are running programs that have been written in assembler
>or compiled to machine language at a previous time.

Linux has marked the text segment RX (no W) since forever (at least
since QMAGIC binaries, probably earlier), and it has not been alone in
this.

IIRC malloc()ed memory has been RW (no X) since the early 2000s.

So the only ones who get WX memory are those who ask mmap(),
mprotect() and friends for it. E.g., JIT compiler writers are doing
that.

>well, is the fact that people can
>break windows a reason not to lock your front door?

Dian Thomas told us when we asked about leaving her Jeep open that she
does not want a wannabe thief to have to cut through the
(soft-plastic) window to find out that there is nothing to steal in
there.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>