Re: [9fans] authorization schemes (was CORBA)

Re: [9fans] authorization schemes (was CORBA)

[rob pike]

Copy on write is easy on a uniprocessor. It gets nastier on
a multiprocessor.  Our solution was to switch to copy on
reference on the MP.

-rob

Re: [9fans] authorization schemes (was CORBA)

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> Copy on write is easy on a uniprocessor. It gets nastier on
> a multiprocessor.  Our solution was to switch to copy on
> reference on the MP.

It can be a nice strategy to use copy-on-write to hold things like
libraries shared by many processes.  Then if one process happens to
get a breakpoint, the debugger can just write the library page in that
process's image, and the copy-on-write does the right thing.  Normal
processes all happily share.

Doesn't that break if you use copy on reference?  

Perhaps I'm misunderstanding you...

Re: [9fans] authorization schemes (was CORBA)

[forsyth]

>>I lost track and forget we weren't talking reference bits ...

my fault, possibly.  i'd forgotten which bit the vax didn't provide;
apparently it was reference not modify.
it doesn't matter.  the algorithm was a waste of time and space
all the same.  their literature search must have been perfunctory.

Re: [9fans] authorization schemes (was CORBA)

[rob pike]

Boyd's right on this one: vfork was done for the 780.
The 750, being a different implementation, had different
MMU peculiarities, and there were some difficulties getting
COW to work on it.  I remember John Reiser struggling with
it for 32V.  I believe he eventually conquered it, but it wasn't
easy.

-rob

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

> I remember John Reiser struggling with it for 32V.
> I believe he eventually conquered it, but it wasn't
> easy

i know (his?) 32V non-COW MMU code on the 780 pretty well.

lots of 128's scattered everywhere and that allocated on the
fly bitmap to the SPT, but not zeroed.  the 780 zeroed the
first 64kb, should the pages grabbed for the bitmap be > 64kb
you had a bunch of weird panics and la-120 stack backtraces
all over the place ...

Re: [9fans] authorization schemes (was CORBA)

[forsyth]

> According to some of the Berkeleyites, there was a flaw in
> the VAX-11/750 memory management unit (microcode?) such
> that they were unable to use copy-on-write.

perhaps early 750s had a bug that instructions wouldn't
restart correctly on protection trap, which would prevent emulating
the page-modified bits (i haven't got a vax handbook to hand but
i think those were the bits missing from the page tables), in order
to do copy-on-write, but if the broken hardware would support
any form of paging on the platform, it must have been able
to support copy-on-reference (ie, instructions could be restarted
after page-invalid traps).

mind you, the 750s i had seemed fine with c-o-w.

Re: [9fans] authorization schemes (was CORBA)

[presotto]

I had to do the datakit interface for their system and I seem to remember
we had Blit's around the same time.  If so, the blit did enough of the
work that they could ignore it.  If not, then we wouldn't have had
a window system to worry about.  They solved pipes.

Re: [9fans] authorization schemes (was CORBA)

[presotto]

The real best part was an accidental 'du /|grep pattern' by a
user at a high level user made the whole file system useless to anyone
of lower classification.

Also, terminals were a real pain because their inodes had to
change security level whenever someone new logged in, which
meant chasing down anything somehow related to them.  Not
really in the orange book model.  Network connections were
equally bad.

The real lesson of the experiment was that security level
classification is hard to live with.

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

didn't it also raise the issue of how to handle window
system snarf/pastes between windows given the 'text'
could have different classification levels?

Re: [9fans] authorization schemes (was CORBA)

[Douglas A. Gwyn]

Boyd Roberts wrote:
> didn't it also raise the issue of how to handle window
> system snarf/pastes between windows given the 'text'
> could have different classification levels?

At one point, AT&T/Teletype was marketing a multilevel secure
environment for the 5620 DMD terminal attached to a 3B2
running UNIX System V.

[9fans] authorization schemes (was CORBA)

[Scott Schwartz]

| > ? would be Doug McIlroy and 'The IX Multilevel Secure Operating System'
| > CSTR #163 is available in pieces at http://cm.bell-labs.com/cm/cs/cstr.html.
|
| that'd be it.  iirc they added a chunk of bit vectors to just about
| everything and used simple bitwise operations to implement the security
| with a tiny performance hit.

The best part (cf a paper in Usenix Computing Systems) was that they
caught a virus that someone else accidently unleashed.

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

> The best part (cf a paper in Usenix Computing Systems) was that they
> caught a virus that someone else accidently unleashed.

yeah, i think it was duff.  he'd stick the virus in the last block
of a demand paged binary [0413], jump to it, infect other binaries
and then jump back to main.  i guess it mangled the entry point
in the a.out header and then snarfed it away to jump back to.

by this stage 8/9/10th Ed was being used, which was based on 4.1BSD,
and it had demand paged binaries.

iirc duff had forgotten about this virus.

Re: [9fans] authorization schemes (was CORBA)

[Mike Haertel]

The version of the story that I remember is that Duff wrote the
virus as an experiment and placed it in his own bin directory.
Then he waited to see how long it would take to spread.  It rapidly
spread through their network of research Unix machines.  Its spread
was limited since (almost) nobody else ran v9 Unix.

It was ~300 bytes of Vax machine code that wanted to sit in the
padding of executable text to the next 1K boundary, so on average
about 60% of the binaries had room for it.  It altered the a.out
entry point to point at itself, then jumped to main after doing
its dirty work.  First it scanned the current directory, /bin, and
/usr/bin, looking for executables it could write itself into.

The story I heard, which might have been from Duff, or might have
been from one of the other people there the summer I worked there,
was that he gave a talk about his virus at one of the internal
colloquia, and after the talk their research director came up
and said to him, "That's very interesting, now STOP IT!"

So he had to spend awhile doing "janitorial work" as penance for
his research.

The virus erupted at least one more time from the backup system and
spread throughout their network again.  The main symptom of the
virus is that machines got really slow, since nearly every command
people were running would first search /bin and /usr/bin looking
for programs to infect.

By the time I got there (summer of 1991) the backup system had been
modified to refuse to restore any infected files.

McIllroy's "IX" system detected and stopped the virus.  Actually I
think what happened is that after the virus wrote programs in /bin
under the IX system, the system would refuse to run them any more
since they were possibly contaminated by unauthorized users.  So
the IX system stopped the virus but stopped working in the process.
Arguably better than silently continuing to function whilst infected.

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

> "That's very interesting, now STOP IT!"

yeah i got told to cease and desist, well:

    i think you've proved enough with that experiment now

when i was doing some DES bashing with some of the pre-release
alphas in '93.  found my way into somewhere that you were not
supposed get into that easily.

Re: [9fans] authorization schemes (was CORBA)

[Douglas A. Gwyn]

Boyd Roberts wrote:
> by this stage 8/9/10th Ed was being used, which was based on 4.1BSD,
> and it had demand paged binaries.

you misspelled "damned" there.

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> you misspelled "damned" there.

yeah, i guess i did.  all this got radically 'corrected' in 4.2BSD.

vfork()?  was the v for vomit?

Re: [9fans] authorization schemes (was CORBA)

[Douglas A. Gwyn]

Boyd Roberts wrote:
> vfork()?  was the v for vomit?

According to some of the Berkeleyites, there was a flaw in
the VAX-11/750 memory management unit (microcode?) such
that they were unable to use copy-on-write.  When I
mentioned this to the AT&T UNIX System V developers, they
said it seemed to work fine for them..

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

> According to some of the Berkeleyites, there was a flaw in
> the VAX-11/750 memory management unit (microcode?) such
> that they were unable to use copy-on-write.

yeah, i heard that story about the comet.  we had 780's
and it just worked fine and was faster and cleaner than
vfork.  i got kre to help me run some benchmarks.  vfork
seemed to go to a _lot_ of trouble to do very little.

hell, the whole paging system sucked.

chinese + red book + a weekend's thought = copy on write fork.

Re: [9fans] authorization schemes (was CORBA)

[David Lukes]

> Boyd Roberts wrote:
> > vfork()?  was the v for vomit?

or vegetative ...

> According to some of the Berkeleyites, there was a flaw in
> the VAX-11/750 memory management unit (microcode?) such
> that they were unable to use copy-on-write.

Ummm ... correct me if I'm wrong, but
a) didn't vfork exist before the 11/750?
   I certainly remember having 4.1BSD on a 780 a *long* time before we could buy 750s ...
b) If you can do demand paging correctly,
   then you *must* be able to do COW somehow, albeit possibly horibly inefficiently:
   if necessary, you could do a similar hack to the one they used to fake the
   page-referenced bit
   e.g. turn off page access entirely, take the fault, see what kind of
        fault it was, do what's necessary based on the page type etc.
   All that is required is that the h/w report the access fault type correctly,
   and if it doesn't do that, then COW is the least of your problems ...

>  When I
> mentioned this to the AT&T UNIX System V developers, they
> said it seemed to work fine for them..

Well, ain't that strange:-) ...

Cheers,
	Dave.

Re: [9fans] authorization schemes (was CORBA)

[Ronald G Minnich]

On Mon, 1 Oct 2001, David Lukes wrote:

> > According to some of the Berkeleyites, there was a flaw in
> > the VAX-11/750 memory management unit (microcode?) such
> > that they were unable to use copy-on-write.

11/780 actually was the first machine with the missing bits.

> Ummm ... correct me if I'm wrong, but
> a) didn't vfork exist before the 11/750?

see above. 750 came after 780.

ron

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

From: "Ronald G Minnich" <rminnich@lanl.gov>
> 11/780 actually was the first machine with the missing bits.

bullshit.  i used those bits.

> > Ummm ... correct me if I'm wrong, but
> > a) didn't vfork exist before the 11/750?
> 
> see above. 750 came after 780.

nope, listen to my man dave, one of (if not) the best in europe.

you have no idea ...

Re: [9fans] authorization schemes (was CORBA)

[Ronald G Minnich]

On Tue, 2 Oct 2001, Boyd Roberts wrote:

> From: "Ronald G Minnich" <rminnich@lanl.gov>
> > 11/780 actually was the first machine with the missing bits.
>
> bullshit.  i used those bits.

we're talking about different bits. My fault, I was not paying
attention, sorry.

I lost track and forget we weren't talking reference bits ...

"Ozalp Babaoglu and William Joy. Converting a Swap-Based System to do
Paging in an Architecture Lacking Page-Reference Bits. In Proceedings of
the 8th ACM Symposium on Operating Systems Principles, pages 78--86,
Pacific Grove, California, December 1981."


> > see above. 750 came after 780.
>
> nope, listen to my man dave, one of (if not) the best in europe.

Hmm, a buddy of mine worked on the 780. Plus we bought one or two on
product intro, so I was kind of there for it. So I asked all those neurons
back in the limbic system that were alive back then and they're certain
the 750 was later. But sometimes they like to mess with my head.

The 750 was a truly awful piece of gear.

ron

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

From: "Ronald G Minnich" <rminnich@lanl.gov>
> Hmm, a buddy of mine worked on the 780. Plus we bought one or two on
> product intro, so I was kind of there for it. So I asked all those neurons
> back in the limbic system that were alive back then and they're certain
> the 750 was later. But sometimes they like to mess with my head.

yeah, i was just assuming.  my badge # was 248622, which was well
after the introduction of the vax.

> The 750 was a truly awful piece of gear.

yeah ctrl-p halted the cpu (iirc), but on the 780 it got you into
console mode.  the 780 was _big_, but i could cope with it.

Re: [9fans] authorization schemes (was CORBA)

[Douglas A. Gwyn]

Boyd Roberts wrote:
> yeah ctrl-p halted the cpu (iirc), but on the 780 it got you into
> console mode.  the 780 was _big_, but i could cope with it.

Only when transmitted from the console keyboard.
The fun part was trying to find out how to resume.
Something like SET TERMINAL CONSOLE would do it.

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

> Something like SET TERMINAL CONSOLE would do it.

SET T P would do it iirc.

Re: [9fans] authorization schemes (was CORBA)

[davel]

On Thu, Oct 04, 2001 at 11:28:13AM +0200, Boyd Roberts wrote:
> > Something like SET TERMINAL CONSOLE would do it.
> 
> SET T P would do it iirc.
> 
> 

Yes, "SET TERMINAL PROGRAM" (abbreviated to "SE T P") did it.

("SET TERMINAL CONSOLE" would set it talking to the console processor,
 although you'd only ever use that in console command files).

Also, the console processor was an 11/34 running a hacked up RT/11.

NOW, can we please stop talking about the useable machines we used to have,
and go back to talking about the hideous garbage like USB
that we're currently lumbered with?

Thanks,
	Dave.

Re: [9fans] authorization schemes (was CORBA)

[Boyd Roberts]

> Also, the console processor was an 11/34 running a hacked up RT/11.

on the 780 it was an 11/23 :)

Re: [9fans] authorization schemes (was CORBA)

[Douglas A. Gwyn]

Boyd Roberts wrote:
> > Something like SET TERMINAL CONSOLE would do it.
> SET T P would do it iirc.

Ah: SET TERMINAL PROGRAM.  (I think the other existed also,
but would make send only from a batch file [on the 11/03 control
system].)

Re: [9fans] authorization schemes (was CORBA)

[David Lukes]

> > From: "Ronald G Minnich" <rminnich@lanl.gov>

> > > see above. 750 came after 780.
> >
> > nope, listen to my man dave, one of (if not) the best in europe.

<blush/>

Ummm ... what I said was that _vfork_ came _before_ the 750,
i.e they'd already done the hack before the /750s appeared,
thus the /780 predated the /750.
AFAIK, vfork was done in the name of the great tin god Efficiency,
not because of any real or imaginary h/w problems.

>  So I asked all those neurons
> back in the limbic system that were alive back then and they're certain
> the 750 was later. But sometimes they like to mess with my head.

Not this time: your neurons are accurate.

> The 750 was a truly awful piece of gear.

Amen to that.

Cheers,
	Dave.