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

[Frank T. <fra...@gm...>]

On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote:

> 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.
>
That would explain why so little code changed. This did not occur to me.

At the same time, with processors as fast as they are, the added over-head
of running in direct mode seems a small price to pay for avoiding all of the
pains and woes and sysctl modifications and extra segmentation faults
(beyond those intercepted for various reasons) that result from running in
real mode. It also seems that it might be feasible, if anybody cared enough
and had enough free time, to leverage the virtualization features in modern
processors in order to solve the memory windowing problem better than the
SEGINT handler.


>
> 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.
>
My experience was on the SheepShaver side of things with the awful dyngen
stuff, so I never noticed this. I might have saved myself a lot of trouble
if I had.

On a related note, does anybody know why there are so many good M68K
emulators (Basilisk II, Mini vMac, and, seemingly, whatever Joshua is
writing) and so few good PowerPC emulators? I would have thought (without
actually reading much about the instruction sets) that emulating a RISC
machine with a New World ROM and OpenFirmware ought to be much less
difficult than emulating a CISC machine with all of the crazy ancient
Macintosh stuff.

>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>