Re: Arbitrary Sandbox

[Robert A Duff <bobduff@shell01.TheWorld.com>]

tmoran@acm.org writes:

>> I've never used a Burroughs machine, but it seems to me that a design
>> that requires compilers to run in a privileged mode is just wrong.
>> A goal is to avoid having too much code in privileged mode, and
>> compilers are complicated beasts.
>
>   There was no "privileged mode" or "user mode".  Files on disk had
> various security privileges, and one possibility was "this is a code
> file" while another possibility was "this is a compiler and it's
> allowed to create a file with 'code file' security".

OK, thanks for the clarification -- as I said, I never used one of
those machines.  But I think it amounts to more-or-less the same thing
-- a design that requires compilers to have special privileges
is a bad idea, whether you call that a "mode" or a "per-file privilege
attribute" or whatever.

>...  I imagine the Burroughs compiler writers lived under the
> same situation, except that they could work in the daytime on their
> own "development" machine.

The ones I was talking about _shared_ a machine.  So rebooting it
disrupted the entire project, not just one programmer.

>...I suspect that's the way compiler writers
> work today, each with his own (rebootable) development machine

I'm a compiler writer, and yes, I have my own rebootable development
machine.  But compiler bugs don't require rebooting.  Operating system
kernel bugs do, but that's inevitable, and it's a good reason to
keep the kernel small.

>   Most OS changes did not causes crashes, just undesirable behavior.
> Most compiler bugs don't cause machine crashes, just program errors.
> Since the B5500 had segments with descriptors and hardware checked
> indexing, a bad program would more likely generate a fault ("exception")
> than crash the whole system.

OK.

>   BTW, the only real problem we had with bad user programs was one grad
> student who had heard about "virtual memory" and wrote his program to use
> large arrays.  Unfortunately he accessed them column-wise, while they were
> stored row-wise, so his program swapped horribly.  In 1970 it would have
> taken a very smart compiler indeed to prevent that problem.

That problem still exists.  I've seen cases recently, on both windows
and linux, where a rogue program swapped horribly, and put the system
in a state where it won't listen to the keyboard or mouse, so I can't
kill the program.  It seems to me it's possible to design an OS that
wouldn't do that.

>   We've spent the last half-century making computers faster, with modest,
> or sometimes negative, progress on preventing or catching software bugs,
> so the number of executed bugs/second must be orders of magnitude larger.

Certainly true.  There are also a lot more car wrecks nowadays than
there were 100 years ago.  ;-)

- Bob