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

[Michael S. <msb...@me...>]

On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote:
> 
> 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.
> 
> 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.

Basilisk II supports three types of memory access modes. Which one to use is selected at compile time:

REAL: The addresses seen inside the emulated machine are exactly the same as the host memory address.

DIRECT: The addresses are shifted by a fixed offset. In Basilisk II the offset is a parameter; in SheepShaver it is pre-calculated and compiled into the program.

VIRTUAL:  The guest address space is broken down into banks, e.g. the RAM, ROM and frame buffer are handled separately. It uses some kind of address translation logic.


32-bit SheepShaver on OS X normally runs in REAL mode, for performance reasons.  I'm suspecting that 64-bit SheepShaver still runs in REAL mode, simply allocating the guest memory down in the 32-bit address space.

Since SheepShaver and Basilisk II guests are limited in how much guest memory they could possibly use, being limited to the 4 GB address space isn't a problem if the other memory blocks used by OS X are not in the way.  Where does IOKit land in a 64-bit process?


Anyway... my point is that Basilisk II is not restricted to running in REAL mode. You just need to compile it with different parms.