Re: [B2-devel] Basilisk 2 and The Journeyman Project

[Joshua J. <jj...@gm...>]

On Sep 12, 2011, at 7:40 AM, Frank Trampe wrote:

> There is a rather pervasive problem in the code base of casting  
> pointers to 32-bit integers, which causes a number of problems on  
> 64-bit architectures, like refusal to compile in most cases and  
> total failure at run-time when one gets that far.

Also problematic is the premise of storing host OS pointers in the  
guest OS's memory space.  It opens the door for arbitrary native code  
execution on behalf of an emulated program.  Putting aside the idea  
that someone would write a malicious classic Mac OS program to pwn  
your Intel box (which I admit is far-fetched), it's still plausible  
that misbehaving emulated code could crash the emulator itself.

> There are two possible long-term solutions that seemed plausible a  
> few years ago. One is to preallocate memory for the emulated  
> machine at a full 64-bit address and then to keep 32-bit pointers  
> as internal off-sets in the allocated range. The other is to  
> construct some method for translating between the virtual 32-bit  
> pointers of the guest operating system and the 64-bit pointers of  
> the host, possibly through a look-up table . Both options are  
> extremely costly in terms of time investment. I started working on  
> the first option but became too busy.

I'm writing a new 68K emulator, called v68k.  It's not a full-on Mac  
emulator, but a library that (at least in theory) could be applied  
toward emulation of any 68K platform.  In v68k, memory is modeled in  
the emulator as base pointer and length.  Emulated memory addresses  
are offsets from the base pointer.  The base pointer is compiled  
however the platform wants; it's never stored in emulated memory and  
no magic is required.

Currently there's only one memory region (although a future version  
will support many), but even so, the translator (through which all  
emulated memory accesses are bottlenecked) has some special logic.   
The system vector table (which includes memory address zero, or NULL)  
can't be read or written in user mode and can't be executed even in  
supervisor mode.  The important point is that memory errors are  
caught by the translator and don't leak into the native code.

<http://www.metamage.com/code/v68k/>

Josh