Far and near pointers on the 80286 and later

http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later

part of it was how to cut the development for reliability and security.

we had been called in to consult with small client/server startup that
wanted to do payment transactions on their server. they had some well
designed and well tested application code that would handle the
transactions. I then a bunch of stuff that I claimed was necessary to
take a quality application and turn it into a "service" (aka business
critical, 7x24) ... which took nearly ten times the original application
effort. It included doing some compensating processes and diagnostic
manual for Internet environments.

At the same time there were various milspec security development stuff
that were also being required for critical financial infrastructures
.... stuff like 2167A ... which also took something like ten times the
effort of what might be considered well-designed, well-implemented,
well-tested application (and then re-applied for any
enhancement/changes).

Part of the JAD was could I take both the security & RAS stuff that was
increasing standard application development by a factor of ten times
.... and get it down to maybe only 2-3 times.

misc. past posts mentioning business critical being 4-10 times
standard development for business critical:
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007n.html#10 The top 10 dead (or dying) computer skills
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
http://www.garlic.com/~lynn/2007o.html#23 Outsourcing loosing steam?
http://www.garlic.com/~lynn/2007p.html#54 Industry Standard Time To Analyze A Line Of Code
http://www.garlic.com/~lynn/2007v.html#53 folklore indeed
http://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9
http://www.garlic.com/~lynn/2008e.html#50 fraying infrastructure
http://www.garlic.com/~lynn/2008e.html#53 Why Is Less Than 99.9% Uptime Acceptable?
http://www.garlic.com/~lynn/2008i.html#33 Mainframe Project management
http://www.garlic.com/~lynn/2008n.html#20 Michigan industry
http://www.garlic.com/~lynn/2008n.html#35 Builders V. Breakers
http://www.garlic.com/~lynn/2008p.html#48 How much knowledge should a software architect have regarding software security?
http://www.garlic.com/~lynn/2009.html#0 Is SUN going to become x86'ed ??

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Anne & Lynn Wheeler writes:
At the same time there were various milspec security development stuff
that were also being required for critical financial infrastructures
... stuff like 2167A ... which also took something like ten times the
effort of what might be considered well-designed, well-implemented,
well-tested application (and then re-applied for any
enhancement/changes).


http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#16 Far and near pointers on the 80286 and later

wasn't a member ... but did get invited to some of their meetings ...
somewhat favorite of mine from their website ... courtesy of the wayback
machine:
http://web.archive.org/web/200010181.../frampapr.html

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

wrote:
In article , jmfbahciv jmfbahciv@aol wrote:
There is nothing, I repeat NOTHING, more instructive than working
on a functional system. It's a computer biz law that, what you
expect to happen, will not happen; the corollary is that the
opposite of what you expect to happen will happen. Only
those who have done OS development for many releases will
understand this one.

Not at all. I have never done that, but I have done such things
as implement fully-functional language run-time systems (including
exception handling, non-trivial I/O and associated recovery).

That's almost an OS with a lot of "user-cruft" eliminated ;-).

I am VERY familiar with that principle, and it holds true even
after 40+ years experience ....

Man! It would drive JMF and TW bonkers.

ARe you really sure that MULTICs doesn't have old tricks
which have to be relearned and reimplemented again? I'm
not. I'm sure of the opposite.

I don't object to people reinventing the wheel, but I do wish they
would get the number of sides right!

ROTFLMAO. Yea. That's a much better way of expressing it.


That is especially true as people attempt to use Unix derivatives
(including Microsoft ones, of course) for servers. Mainframes had
lots of defects, but avoided many of the current ones.

That's because they didn't work so the asspects never got shipped.
Nowadays, no OS development cycle seems to have time to find these
things out. Our monitor development cycles were around 2 years
with limited interim releases (LIRs) shipped to support new
hardware.

/BAH

George Neuner wrote:
On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv jmfbahciv@aol wrote:

George Neuner wrote:

Leaving aside why anyone would _want_ to bring back Multics ...
To study how to make an OS secure from the beginning project plan
to the last edit for shipping?

Ok, but there are other secure systems to study such as Amoeba and
EROS. They are more modern than Multics, and in particular, were
designed to be distributed.

I don't mind anyone studying Multic - there is plenty to learn from it
(including what not to do) ... but I would be against trying to revive
it as a working operating system.

One of the things which separated MULTICS from most other operating systems was
the way in which rings were used. Many operating systems use (or mostly use)
only two rings, similarly to the "master mode" and "slave mode" of 1960's
computers. By putting things like libraries and privileged linked programs
(terminology escapes me, it's been ~40 years) in rings, access could be more
nuanced.

In article , says...

George Neuner wrote:
On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv jmfbahciv@aol wrote:

George Neuner wrote:

Leaving aside why anyone would _want_ to bring back Multics ...
To study how to make an OS secure from the beginning project plan
to the last edit for shipping?

Ok, but there are other secure systems to study such as Amoeba and
EROS. They are more modern than Multics, and in particular, were
designed to be distributed.

I don't mind anyone studying Multic - there is plenty to learn from it
(including what not to do) ... but I would be against trying to revive
it as a working operating system.

One of the things which separated MULTICS from most other operating systems
was
the way in which rings were used. Many operating systems use (or mostly use)
only two rings, similarly to the "master mode" and "slave mode" of 1960's
computers. By putting things like libraries and privileged linked programs
(terminology escapes me, it's been ~40 years) in rings, access could be more
nuanced.

Well, the CDC Cyber 180 series (and NOS/VE) did something similar.

- Tim

Tim McCaffrey wrote:
In article , says...
George Neuner wrote:
On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv jmfbahciv@aol wrote:

George Neuner wrote:

Leaving aside why anyone would _want_ to bring back Multics ...
To study how to make an OS secure from the beginning project plan
to the last edit for shipping?
Ok, but there are other secure systems to study such as Amoeba and
EROS. They are more modern than Multics, and in particular, were
designed to be distributed.

I don't mind anyone studying Multic - there is plenty to learn from it
(including what not to do) ... but I would be against trying to revive
it as a working operating system.

One of the things which separated MULTICS from most other operating systems
was
the way in which rings were used. Many operating systems use (or mostly use)
only two rings, similarly to the "master mode" and "slave mode" of 1960's
computers. By putting things like libraries and privileged linked programs
(terminology escapes me, it's been ~40 years) in rings, access could be more
nuanced.

Well, the CDC Cyber 180 series (and NOS/VE) did something similar.


OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Peter Flass wrote:
Tim McCaffrey wrote:
In article ,
says...
George Neuner wrote:
On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv jmfbahciv@aol wrote:

George Neuner wrote:

Leaving aside why anyone would _want_ to bring back Multics ...
To study how to make an OS secure from the beginning project plan
to the last edit for shipping?
Ok, but there are other secure systems to study such as Amoeba and
EROS. They are more modern than Multics, and in particular, were
designed to be distributed.

I don't mind anyone studying Multic - there is plenty to learn from it
(including what not to do) ... but I would be against trying to revive
it as a working operating system.

One of the things which separated MULTICS from most other operating
systems
was
the way in which rings were used. Many operating systems use (or
mostly use) only two rings, similarly to the "master mode" and "slave
mode" of 1960's computers. By putting things like libraries and
privileged linked programs (terminology escapes me, it's been ~40
years) in rings, access could be more nuanced.

Well, the CDC Cyber 180 series (and NOS/VE) did something similar.


OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Yes, that's a much more MULTICS model, allowing drivers and system support to
run at "more than user" to access devices, raw memory, etc.

Bill Davidsen writes:
One of the things which separated MULTICS from most other operating
systems was the way in which rings were used. Many operating systems
use (or mostly use) only two rings, similarly to the "master mode" and
"slave mode" of 1960's computers. By putting things like libraries and
privileged linked programs (terminology escapes me, it's been ~40
years) in rings, access could be more nuanced.

370xa started out with access registers and then added program call (&
return).

issue was that favorite son batch operating system heritage (from real
memory environment) was extensively pointer-passing API.

In the initial transition to virtual memory (OS/VS2 SVS) it was just a
single large virtual memory (pointer-passing APIs still working).

In the migration to MVS ... each application was given its own address
space ... but an image of the MVS kernel appeared in (8mbyte) half of
each (16mbyte) virtual address space (pointer passing API easily worked
since MVS kernel code as in the same address space of each application).

The problem was that there were a lot of "subsystems" (semi-privileged
operations) that had resided outside the kernel (called by applications
with pointer passing API) that were now in their own virtual address
space (i.e. application would generate system call and the kernel would
invoke the subsystem in its own virtual address space).

To continue with pointer-passing API, a "common segment" was created
that also resided in each virtual address space. This started out was
1mbyte of each virtual address space ... but grew ... somewhat
proportional to the number of independent subsystems and the number of
concurrent executing applications. eventually in the timeframe of of
large 3033s ... common segments were threatening to exceed five mbytes
(growing to six ... leaving only 2mbytes for applications in each
application virtual address space).

to start to address the problem ... a subset of 370xa access registers
were introduced in 3033 called dual-address space mode. Application wold
make kernel call to invoke subsystem, kernel would swap the home &
alternate virtual address space pointers before invoking the
subsystem. each instance of subsystem execution would have alternate
address space pointer to its invoking application ... and could directly
address the invoking applications virtual address space.

Now 370xa introduced introduced access registers with more generalized
implemenation of dual-address space as well as 31bit virtual addressing
(31bit virtual addressing would have alleviated the common segment
attempting to completely take-over remaining application area in each
virtual address space).

program call (& return) ... application instruction that references a
kernel hardware table ... that defines available "subsystems" and the
rules for changing around the address space pointers. now applications
can directly invoke a subsystem in different address space, w/o the
overhead of kernel call processing (much like a library routine call
that resides in the same address space).

description of program call
http://publibz.boulder.ibm.com/cgi-b...20040504121320

program return
http://publibz.boulder.ibm.com/cgi-b...20040504121320

discussion of access registers ("current instruction space and a maximum
of 15 other spaces)
http://publibz.boulder.ibm.com/cgi-b...20040504121320

discussion of address spaces
http://publibz.boulder.ibm.com/cgi-b...20040504121320


recent posts mentionin dual-address space &/or access registers:
http://www.garlic.com/~lynn/2010c.html#41 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010d.html#81 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#75 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#76 LPARs: More or Less?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

In article ,
Bill Davidsen wrote:
Peter Flass wrote:

OS/2 uses three: one for the kernel, one for drivers, etc., and the
third for user programs.

Yes, that's a much more MULTICS model, allowing drivers and system support to
run at "more than user" to access devices, raw memory, etc.

Typical operating system centricity :-(

A massive gain in RAS could be obtained by allow multiple 'rings'
of protection at the application level. It would enable reliable
run-time systems, debuggers and run-time diagnostics, and increase
the number of bugs that were actually located rather than simply
being hacked around until they now longer showed up.

This would make an INCREDIBLE difference to the RAS of parallel
support and the hairy asynchronous 'libraries', such as windowing
systems. At present, it's infeasible even to report bugs in most
of those, because they aren't repeatable and can't be proved not
to be user errors. But, if the component were in a protected
environment, a dump showing that privilege level would be clear
evidence of a bug.

Yes, that would mean the vendors of such things improving their
standards, but at present they have no incentive to ....


Regards,
Nick Maclaren.

wrote:

A massive gain in RAS could be obtained by allow multiple 'rings'
of protection at the application level. It would enable reliable
run-time systems, debuggers and run-time diagnostics, and increase
the number of bugs that were actually located rather than simply
being hacked around until they now longer showed up.

Yeah. That's one of the nice things about a capability architecture,
like the AS/400 / iSeries / System i family. Much better protection
granularity means much better (more aggressive and precise) error
detection.

On the '400, an off-by-one logic mistake overruns a buffer and you
find out right away, with a check message that includes a stack trace
sent to your message queue; you could terminate the job or break into
the debugger to investigate further.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University