20 Aug
2006
20 Aug
'06
12:32 a.m.
Josh Dersch wrote:
Don wrote:
Of course.
Josh Dersch wrote:
Or if you, for example, create a CPU that executes IL natively. See
LispMs from the late 70s/early 80s for a different example of this.
There's no reason a modern equivalent couldn't be made. You may be interested in the Singularity project
(a research project
at Microsoft, no less). It (gasp!) abstracts away pointers; the IL
used for the entire OS (a subset of the CLR), the OS interface, et.
al. is designed such that processes can be "proven" to be safe -- and
all process protection is done _without_ the use of any CPU hardware.
http://research.microsoft.com/os/singularity/
This can only be possible if applications are *interpreted*
AND the user is denied *any* means of accessing the underlying
hardware (either by accidental or *intentional* means).
It's like claiming "run Java/Inferno/etc. on your machine and you'll
never have to worry about security issues" (unless, of course,
someone boots the machine to a "non-Java" state!) In addition, the applications on Singularity (or
Java/.NET today) are
not *interpreted*. They're jitted, which is far more performant.
But the intent was to avoid the "performance penalties"
of using hardware mechanisms. So, (in existing hardware)
you trade the use of those facilities for the overhead of
an interpreter (regardless of what you want to call it)
On typical PC hardware, yes, for an OS like this there
needs to be an
abstraction layer that lies between the "dangerous" physical hardware
and the safe IL domain; this abstraction layer can be made very small
and as such can be rigorously debugged. This abstraction layer
_completely_ prevents access to the underlying hardware, or other
application's process spaces.
As far as "booting the machine to a "non-Java" state... if you (as an
evil haX0r) have physical access to the hardware and can boot the
machine to a different OS, then yes, all bets are off... I'm not quite
sure what the point of that argument is.
Because most machines nowadays are in the hands of people who
aren't savvy enough to understand these issues. I.e. you can't
have physical security since there is nothing preventing a
user (*owner*) from circumventing this key step knowingly or
unknowingly.
E.g., any sort of removable media that can be passed control
of the processor outside (i.e., before) the scope of your VM
leaves the system vulnerable. Hence the reason many PC's
are configured without (or with *disabled*) floppy and/or CD-ROM
drives in business environments.
Getting a robust system into a consumer's hands is considerably
harder than one sitting in a machine room :>