Re: [off-topic] Fully virtualisable CPUs

Albert Cahalan (
Sun, 8 Sep 1996 18:34:45 -0400 (EDT)

>> Yeah it would run slow the first few times a process ran, but it would
>> leave a long trail of compiled piecelets, and without too much
>> difficulty that could be cached on disk along with the executable so
>> that next time the executable was run the loader would load the
>> cache'd interpreted reassembled progress. In this way, one could even
>> boot a new version of Linux in a Linux window, or FreeBSD, or NT, or
>> Windows '95, or ... CP/M :) or Solaris 'x86 ... Heck I can do this

> What you are describing by the way is how things like the Executor Mac
> emulator do to get fast Mac emulation on a Linux box. Before you leap
> boldly into action remember some little 'catches'

He would not need to translate code at all, just search for evil code.
He could scan forward to the nearest jump, then leave a debug breakpoint.
When the CPU hits the breakpoint, scan again. You end up with breakpoints
before all the unknown code (jumps never taken) and at spots where some
evil code must be emulated.

> 1. You have to play with mmap and mprotect as well since there are
> side effects you have to emulate (page table dirty bits for example), and
> some memory writes eg to the page tables affect the emulator however they
> are done by the process you are running.

I suspect you could leave the dirty bit set. The important thing would
be to only set the breakpoints where the client OS thinks it has ring 0.
The apps running in the client OS should not think they have ring 0.
Then you can run 32-bit DOS games in an OS/2 window running in a Linux
i386 emulator.

> 2. Self modifying code
> 3. Even worse, code that looks at itself to see if it needs to self
> modify this time.

Only Linux would do something like that. The only two suggestions
I've heard for i386 Linux were not implemented anyway.

Well, a DOS virus would use self modifying code but I don't mind
if they crash in the emulator. Perfect emulation has disadvantages.