Far and near pointers on the 80286 and later

And segmentation hasn't been used by any production operating
system on ia32 since the 386; [...]

Untrue. It has been used on all of them. In addition to the
obvious requirements at the systems programming level, some of them
permit (or even require!) applications softwares to know of it.
Multithreaded applications programming on 32-bit OS/2 and (x86)
Win32 can involve the explicit use of the FS register by
applications softwares, for example.

They're using FS (and GS) as base registers, not technically as
segments, since the storage referred to by FS is also visible via DS
and CS (which both flat map the entire 4GB).

That's a fairly weaselly distinction. "Using segmentation" isn't
restricted to segments never overlapping or aliasing one another.
Indeed, that's a common thing that production x86 operating systems
do with segmentation, from the aforementioned TIB segments in 32-bit
OS/2 and Win32 to creating data selector aliases for code segments
via DPMI in DOS-Windows 3.1/9x/ME.

Granted, although I'd not call either OS/2 or Win32 running DOS as
modern operating systems.

TIB segments are native 32-bit programming entities. They have nothing
at all to do with OS/2 or Windows NT Virtual DOS Machines. They are
entities dealt with in ordinary Win32 and 32-bit OS/2 programs.

But fundamentally, in both Windows (NT4+) and Linux, segmentation is
only used insofar as the legacy architecture requires it (e.g. CPL
changes) transitioning from real-mode through protected mode to
paging, then long mode; Were other methods available or if they're
added, segmentation would be relgated to the junk heap of history.

That's the point, though. It has not been so relegated, and it is not
the case that it isn't, or even hasn't been, used by production
operating systems. As explained, production operating systems use it
all of the time, even today, and have done in the past, certainly since
the advent of the 80386.

"legacy" doesn't mean what you think, by the way.

George Neuner wrote:
On 22 Mar 2010 23:09:34 GMT, Seebs wrote:

On 2010-03-22, Jonathan de Boyne Pollard wrote:
You make the point for me, would you but realize it. Intel was spending
its time and effort doing things the "right" way, which is why it took
"so long" for x86-64 to become widespread across the board.
Time from first distribution of x86-64 to at least two major
vendors shipping parts in large quantities: ???

Time from first distribution of IA64 to at least two major
vendors shipping parts in large quantities: ???

I wouldn't say that x86-64 took long to become widespread, compared with
IA64. I'm also not at all sure that IA64 counts as doing things the "right"
way.

So far, the largest impact I've seen from IA64 is that it's increased
confusion because people keep thinking it means x86-64.

Untrue. It has been used on all of them. In addition to the obvious
requirements at the systems programming level, some of them permit (or
even require!) applications softwares to know of it. Multithreaded
applications programming on 32-bit OS/2 and (x86) Win32 can involve the
explicit use of the FS register by applications softwares, for example.
I was not aware of any remaining uses of the segmented address space stuff
in modern BSD or Linux on x86. So far as I can tell, they jump into the
flat memory model and stay there.

Most 32-bit x86 OS's defined 2 segments representing user and kernel
mode spaces. This was done because the x86's protection ring traps
were based on the ring bits in the segment selector.

x86-64 still has protection rings although it only implements rings 0
and 2 (the others being rarely, if ever, used). Ring traps are now
triggered on a kernel mode bit in the page address.

If anyone ever ports MULTICS to modern CPUs, the rings will all be used again.
Actually MULTICS run eight rings, but half were used to run stuff in debug mode,
IIRC. That was a *long* time ago.

32-bit Linux and Windows use the FS register to point to thread
information blocks. FS still works in compatibility mode on x86-64.
In long mode the GS register is used for this purpose although the
segment selector is not checked and the value is simply used as a
pointer.

George

On Sat, 27 Mar 2010 17:03:41 -0400, Bill Davidsen
wrote:

George Neuner wrote:
On 22 Mar 2010 23:09:34 GMT, Seebs wrote:

x86-64 still has protection rings although it only implements rings 0
and 2 (the others being rarely, if ever, used). Ring traps are now
triggered on a kernel mode bit in the page address.

^ should have been a "3"


If anyone ever ports MULTICS to modern CPUs, the rings will all be used again.
Actually MULTICS run eight rings, but half were used to run stuff in debug mode,
IIRC. That was a *long* time ago.

Leaving aside why anyone would _want_ to bring back Multics ...

ia32 has only 4 hardware rings. x86-64 in native long mode really has
only kernel/user separation and does not implement protection rings as
such. I'm not sure it _really_ implements rings even in compatibility
mode - I don't know for sure but I suspect the kernel mode trap
creates the illusion of rings and that setting the ring bits on any
segment to anything other than "3" simply results in all the segments
pages being marked as kernel mode.

George

George Neuner wrote:
On Sat, 27 Mar 2010 17:03:41 -0400, Bill Davidsen
wrote:

George Neuner wrote:
On 22 Mar 2010 23:09:34 GMT, Seebs wrote:

x86-64 still has protection rings although it only implements rings 0
and 2 (the others being rarely, if ever, used). Ring traps are now
triggered on a kernel mode bit in the page address.

^ should have been a "3"

If anyone ever ports MULTICS to modern CPUs, the rings will all be used again.
Actually MULTICS run eight rings, but half were used to run stuff in debug mode,
IIRC. That was a *long* time ago.

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?

snip

/BAH

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.

George

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.

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.

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.


/BAH

George Neuner writes:
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.

as an aside ... some of the ctss people went to 5th flr, 545 tech sq to
do multics and others went to the science center on the 4th flr and did
(virtual machine) cp40 (on special modified 360/40 with virtual memory
hardware) which morphed into cp67 (when standard virtual memory 360/67
became available) and then morphed into vm370.
http://www.garlic.com/~lynn/subtopic.html#545tech

Old reference to Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

multics page
http://www.multicians.org/multics.html

old post in multics news group (AFDS was Multics installation)
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia

with respect to cp67 ... there seemed to have been a lot of these guys
.... but I didn't become aware of them until much later:
http://www.nsa.gov/research/selinux/...409/8362.shtml

I did assurance panel discussion at 2001 IDF in tcpa track ...
http://web.archive.org/web/200111090...asp?id=stp+s13
with their technical director
http://web.archive.org/web/200111061...s.asp?id=bsnow

Coyotos is successor to EROS ... EROS was based on tymshare's (370)
gnosis capability operating system ... which was spun off as keykos when
m/d bought tymshare (I was brought in to do gnosis audit/review as part
of the spin-off).
http://en.wikipedia.org/wiki/Coyotos

There were also some number of "object" operating system efforts
.... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink
technology went to Taligent ... and (possibly) some of SPRING/DOE shows
up in java (and java virtual machine)

Recent reference about being asked about coming in to head up
commercialization of SPRING/DOE for shipping as product
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing

misc. past posts mentioning gnosis, keykos, eros, coyotos
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#43 Secure design
http://www.garlic.com/~lynn/2005d.html#50 Secure design
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007o.html#25 LAX IT failu leaps of faith don't work
http://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript
http://www.garlic.com/~lynn/2008b.html#24 folklore indeed
http://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2008e.html#12 Kernels
http://www.garlic.com/~lynn/2008g.html#7 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008g.html#23 Doug Engelbart's "Mother of All Demos"
http://www.garlic.com/~lynn/2008h.html#14 Two views of Microkernels ( Kernels
http://www.garlic.com/~lynn/2008s.html#3 New machine code
http://www.garlic.com/~lynn/2009b.html#4 Possibility of malicious CPUs
http://www.garlic.com/~lynn/2009f.html#28 Opinion: The top 10 operating system stinkers
http://www.garlic.com/~lynn/2010d.html#84 Adventure - Or Colossal Cave Adventure

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

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).
I am VERY familiar with that principle, and it holds true even
after 40+ years experience ....

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!

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.


Regards,
Nick Maclaren.

On Tue, 30 Mar 2010 10:13:07 -0400, Anne & Lynn Wheeler
wrote:


George Neuner writes:
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.

as an aside ... some of the ctss people went to 5th flr, 545 tech sq to
do multics and others went to the science center on the 4th flr and did
(virtual machine) cp40 (on special modified 360/40 with virtual memory
hardware) which morphed into cp67 (when standard virtual memory 360/67
became available) and then morphed into vm370.
http://www.garlic.com/~lynn/subtopic.html#545tech

Yup. Multics did a lot of things first and got quite a bit of it
right. Internally, at least, Multics was quite nice. However, the
security API was not fun to work with and the user experience could be
unpleasant at times. I personally did not use Multics extensively,
but I know people who did and many of them disliked it - as I did.

Of course, I also disliked using VMS ... so I'm probably going to be
cast out 8) I quite enjoyed programming VAXen, but I was much happier
using Unix than VMS.


Coyotos is successor to EROS ... EROS was based on tymshare's (370)
gnosis capability operating system ... which was spun off as keykos when
m/d bought tymshare (I was brought in to do gnosis audit/review as part
of the spin-off).
http://en.wikipedia.org/wiki/Coyotos

Coyotos seems still to be a research project. CapROS, though is a
commercial spin off of EROS. http://www.capros.org/


There were also some number of "object" operating system efforts
... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink
technology went to Taligent ... and (possibly) some of SPRING/DOE shows
up in java (and java virtual machine)

Pink wasn't designed with security in mind (Apple was still thinking
single user) and it never really materialized anyway. Taligent's OS
was more focused on being reliable than being secure.

EROS (and follow-ons) and Amoeba were designed from the ground up as
capability based secure operating systems.

George

George Neuner writes:
Pink wasn't designed with security in mind (Apple was still thinking
single user) and it never really materialized anyway. Taligent's OS
was more focused on being reliable than being secure.


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

I did a one week JAD with taligent (there were dozen or so top taligent
people in the session and their JAD person) going over what would be
required for business critical (both reliable and secure).

the net was approx. 30% hit to the taligent base ... two new frameworks
plus hits to the existing frameworks.

However, I believe the taligent security guru was on business trip that
week ... visiting some gov. agency on the east coast.

misc. past posts referencing the taligent JAD:
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2007m.html#36 Future of System/360 architecture?
http://www.garlic.com/~lynn/2008b.html#22 folklore indeed
http://www.garlic.com/~lynn/2009m.html#26 comp.arch has made itself a sitting duck for spam

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