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

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

On Sep 16, 2011, at 3:55 AM, Joshua Juran wrote:

> On Sep 16, 2011, at 12:41 AM, Frank Trampe wrote:
> 
>> 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.
>>>> 
>>>> 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 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.
> 
> v68k is using a hybrid of DIRECT and VIRTUAL.  There's only one bank  
> at the moment, but translation is always bounds-checked and the first  
> 1K is treated specially.
> 
>>> 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.
> 
> Your performance win is my security hole. :-(  Again, not that  
> someone's going to exploit it -- I just don't want the emulator  
> crashing.  On the other hand, SheepShaver doesn't handle hardware  
> exceptions anyway, so it's kind of moot.

I'm not sure there is a security hole.

From what I recall, neither Basilisk II nor SheepShaver allow guest addresses that are out of the range of the guest address space (which in turn is limited by how much RAM you are emulating.)

In some modes emulator code is being used to map addresses and emulate instructions.  In these modes it can simulate seg faults.

But even if it is running in REAL mode, virtualized, the guest OS still knows what the address space is supposed to be and it can through seg faults if you attempt to exceed it.

So what the malware would need to do in that case is patch the ROM code to bypass those checks.


>> 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.
> 
> I concur.  As time passes, portability and robustness become more  
> important and optimization less so.

I would say that the reason SheepShaver doesn't use DIRECT mode is that, inexplicably, it is not as advanced as in Basilisk II.

In B2 DIRECT mode works by allocation of the guest memory block anywhere the host can find space, and then B2 calculates the resulting offset.

In SS the offset is calculated at compile time. But this only works if each user compiles the code!  And, if you apply an upgrade to your machine (thus changing the library address randomization) it invalidates the compiled-in offset. You would need to keep recompiling it. Of course this is completely non-portable.

Also, consider that both B2 and SS support running the guest on the same processor type as the host, e.g. SS can run on a PowerPC host and B2 can run on a 68k host.  When running in this mode, REAL mode allows it to run virtualized instead of emulated.

(Neither program is smart enough to use the host to do the memory address translation in hardware. )

> 
>> 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.
> 
> I assume you mean SIGSEGV.  I maintain that illegal memory accesses  
> should not be caught but prevented in the first place.

And one of SheepShaver's faults is it doesn't emulate the MMC, which does limit what programs it can run. For example that is one of the problems with later versions of QuickTime.


>>> 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?
> 
> Let's see:
> 
> * m68k has been around about 15 years longer, so there's been more  
> time to write emulators for it
> * m68k has been used for Mac, Atari, Amiga, Sun, Palm, and various  
> other legacy systems, so there's demand for it, whereas PowerPC's  
> only major legacy system is Macs -- and most users had switched to OS  
> X and had little reason to emulate OS 9 and no reason to emulate OS  
> X / PPC.
> * by the time PowerPC shipped, there were fewer Mac-only programs  
> (since Windows was so dominant)
> * PowerPC apps are more likely to have been ported at least to  
> Carbon, and therefore runnable in OS X
> * actual 68K Macs are much slower than PowerPC Macs and therefore  
> more in need of emulators to replace them
> * personally, I find 68K more fun to work with :-

PowerPC emulation died off as soon as OS X started running on Intel. For example, that immediately put a halt to PearPC development.

And as Joshua pointed out, there isn't much else that runs on PowerPC that isn't also available in Intel. For example, while you could compile your favorite Linux distribution for PowerPC, you can also compile for Intel and run natively. 


By the way, I don't think the problem with SheepShaver is the PowerPC emulation part. It is everything else.

A typical PC emulator works by emulating of the complete hardware: CPU, video, network, sound, memory, time controller, interrupts, disk drives, USB, BIOS, etc.  Any OS that can run on a real PC with the same hardware (e.g. the same model of Ethernet card) can run, unmodified, on the emulated machine.

The emulator then typically provides some kind of "Tools" you can install that will modify the running OS to improve performance.

From what I can tell SheepShaver doesn't do that at all.

Instead it is all Tools.  It works by patching the hell out of the Mac OS.  It patches every part of the Mac OS (by hooking the ROM) that deals with hardware, directing it instead to routines in the emulator code.

The downside is that to understand what it is doing you must have an extremely in depth knowledge of how classic Mac OS works. And who knows that anymore?

> 
>> 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.
> 
> Well, v68k knows nothing of Mac hardware -- it's just a 68K emulation  
> library.  But you could write a v68k-based Mac emulator -- that's  
> just not one of my priorities at the moment.  My first v68k client  
> provides a native system call bridge, for running Unix programs.   
> Right now, if you built rot13 for MacRelix (and extracted the code  
> resource into its own file), it would also run in v68k-exec:
> 
> 	$ echo Foo bar | v68k-exec rot13.68k
> 	Sbb one
> 
> As for Mac support, I'd be interested in bridging apps directly to  
> the host OS (in the manner of Wine or GrayBox) before I wrote yet  
> another Mac emulator.
> 
> Josh
> 
> 
> 
> ------------------------------------------------------------------------------
> 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