Okay, I know some about
the details of IBM's VM
and a little about VMware.
I have wondered: The way
VM has worked on IBM mainframe
instruction set has been
partly due to an accident of
the design of that instruction
set and, then, some extensions
for VM. Really, that way, tough
for the program running to
know if it is running as a
virtual machine or not. So,
in particular, the program
running on VM can
be using privileged
instructions and not know
that it doesn't really
have access to the real hardware.
So
I've wondered
if the Intel x86 instruction set
also has this accident and, thus,
can run operating systems that
use privileged instructions
but not know they are running
on a VM. Or maybe the ability
to run on a VM was from some
extensions to the Intel
instruction set. Do you know?
Does the Microsoft CLI/CLR
software have some
security features beyond
just any native program
in, say, Fortran or assembler
running in an address space,
process, or whatever Microsoft
calls where a program runs?
I'm beginning to get the
prerequisites for reading
the OP, that is, understanding
what the long standard alternative
to native code has been.
Heck, I can understand native
code -- at one time I
entered some simple programs
via the computer console
sense switches. And I printed
out the object listing
from a Fortran compiler
and went over the
machine language instructions
one by one. I discovered that
even for some simple code
and a good Fortran compiler,
assembler could be faster
by a factor of several.
> So I've wondered if the Intel x86 instruction set also has this accident and, thus, can run operating systems that use privileged instructions but not know they are running on a VM. Or maybe the ability to run on a VM was from some extensions to the Intel instruction set. Do you know?
No, originally x86 was very difficult to emulate in a virtual machine. User-mode can be run directly on the processor but, for kernel-level code, binary translation was necessary to dynamically re-write the code containing privileged instructions. However, these days nearly all modern x86 processors now have extra instructions specifically for virtualization.
> Does the Microsoft CLI/CLR software have some security features beyond just any native program
There are a bunch of sandboxing features available in the CLR but most applications run with full trust and can do anything a native program can do.
Okay, I know some about the details of IBM's VM and a little about VMware.
I have wondered: The way VM has worked on IBM mainframe instruction set has been partly due to an accident of the design of that instruction set and, then, some extensions for VM. Really, that way, tough for the program running to know if it is running as a virtual machine or not. So, in particular, the program running on VM can be using privileged instructions and not know that it doesn't really have access to the real hardware.
So I've wondered if the Intel x86 instruction set also has this accident and, thus, can run operating systems that use privileged instructions but not know they are running on a VM. Or maybe the ability to run on a VM was from some extensions to the Intel instruction set. Do you know?
Does the Microsoft CLI/CLR software have some security features beyond just any native program in, say, Fortran or assembler running in an address space, process, or whatever Microsoft calls where a program runs?
I'm beginning to get the prerequisites for reading the OP, that is, understanding what the long standard alternative to native code has been.
Heck, I can understand native code -- at one time I entered some simple programs via the computer console sense switches. And I printed out the object listing from a Fortran compiler and went over the machine language instructions one by one. I discovered that even for some simple code and a good Fortran compiler, assembler could be faster by a factor of several.
Just read the Wikipedia article. Nice and easy.
Thanks.