Re: How to develop a random number generation device

On Sat, 15 Sep 2007 11:42:00 -0700, John Larkin wrote:

On Sat, 15 Sep 2007 18:31:41 +0100, Nobody <nobody@xxxxxxxxxxx> wrote:

On Sat, 15 Sep 2007 07:14:28 -0700, MooseFET wrote:

Please explain how "An OS can surely make it impossible to write safe
code and a real OS is required to make safe code possible" addresses the
question of whether the OS can prevent buffer overruns.

You seem to be confusing "Windows" and an "OS".

You seem to be confusing whether it is possible to address an issue with
whether a particular statement actually addresses the issue.

Please read my actual question, quoted above, and removed from any
irrelevant context which might confuse the issue.

FWIW, I have no problem with either "An OS can surely make it impossible
to write safe code" or "a real OS is required to make safe code possible".
However, they don't appear to address the question which was actually
being asked.

If it helps, that question can be rephrased as whether an OS (any OS)
can "make unsafe code impossible", which is a different property to either
of those given.

AFAICT, you cannot do this without sacrificing the ability to run
arbitrary chunks of machine code, which appears to be a "must have"
feature for any OS (if there are OSes which don't allow this, they have
yet to escape from the lab).

I used to run a PDP-11 timeshare system, under the RSTS/E os. It would
run, typically, a dozen or so local or remote users and a few more
background processes, system management and print spooling and such.
Each user could dynamically select a shell, a virtual OS, to run
under, and could program in a number of languages, including assembly,
and run and debug the resulting machine code. You could also run ODT
(like "debug"), poke in machine instructions, and execute them.
Non-priviliged users could do all this, and crash their own jobs, but
they absolutely could not damage the OS or other user tasks. In a
hostile environment (we sold time to four rival high schools, who kept
trying to hack one another) the system would run for months,
essentially between power failures.

This OS, and RSX-11, and TOPS-10, and VMS, and UNIX, and no doubt many
more, from other vendors, *did* escape from the lab.

You and I are talking about different issues. Process isolation has been
solved, even on mainstream OSes.

I'm not talking about process isolation. I'm talking about the ability to
make a program behave other than how its author intended by overrunning a
a buffer (e.g. by making some portion of its input larger than the buffer
in which it will be stored).

.

Quantcast