emaculation / macemu

Basilisk II and SheepShaver Macintosh emulators, maintained
74 stars 14 forks source link

Change SheepShaver default build to direct addressing. #142

Open SegHaxx opened 4 years ago

SegHaxx commented 4 years ago

Modern security standards mean real addressing is not possible on Linux/FreeBSD systems going forward. Instead of disabling security measures, simply use direct addressing instead.

If you are attached to real addressing for some reason, you are free to override the default build. :)

fixes #135

SegHaxx commented 4 years ago

I'll note on both my current systems of interest, Debian aarch64 and CentOS 8 x86_64, I have tried to use the vm.mmap_min_addr=0 workaround, and have even booted CentOS 8 with SELinux entirely disabled, and still can not get mmap at 0x0 to work on these systems. It just doesn't work for me.

Yeah JIT doesn't seem to work here but given it's a checkbox these days I don't see that it needs to be disabled at compile time.

rakslice commented 4 years ago

Do you really mean the actual mmap at 0 is failing? Or just that the build where that happens is crashing?

SegHaxx commented 4 years ago

I mean Linux will refuse to put the mapping at 0x0, and if you request 0x0 you will get back a random address higher in memory. Likely well past 32-bit addressing on 64bit platforms.

rakslice commented 4 years ago

As far as the crash during boot with x86_64 jit false goes, I noticed that a build with -O0 rather than -O2 does boot to desktop. -O0 with jit false is too slow to be useful for much, but it does suggest the path of divide-and-conquering to figure out what is wrong.

IIRC (somewhat more) alive forks and upstream also have that problem that x86_64 linux JIT on works and JIT off doesn't.

rakslice commented 4 years ago

The real addressing build I'm testing in x86_64 Linux is in Debian 9 running kernel 4.9.0-14. mmap of 0 must work there or else I'm really misunderstanding the situation?

SegHaxx commented 4 years ago

Well my Raspi4 is Debian 10.6. :) It seems to be a real recent change to disable the 0x0 mapping. I could maybe try firing up Debian 9 in a VM and see if that works.

rakslice commented 4 years ago

I've got a Centos 8 VM I've probably never used for this before, hold on gotta build SDL2 from source :/

rakslice commented 4 years ago

Anyway, for the purpose of this particular pull request, making direct the default addressing mode, the issue I raised is that it makes builds that use the pregenerated JIT stuff that captures the real addressing mode configuration they were built with immediately crash which is not great in the default configuration. I assume rerolling the pregenerated JIT stuff for direct addressing is beyond the scope of the work you wanna do, so just making JIT not the default for the cases where it would use the pregenerated stuff is the present task? This means I guess figuring out the logic of configure.ac for deciding what the default configuration is for JIT to figure out what cases need to change, and then reworking it for JIT to not be the default in those cases.

rakslice commented 4 years ago

On my Centos 8 VM Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux the default value of mmap_min_addr is 4096. For a change to the setting to even take, SELinux has to be set to not enforcing. And regardless of what mmap_min_addr it is set to, when SELinux is enforcing, SheepShaver fails with

ERROR: Cannot map Low Memory Globals: Permission denied.

However with SELinux set to not enforcing, it's possible to set mmap_min_addr to 0, in which case SheepShaver runs and works (at least for the first few minutes of the 7.6.1 install that I've had time to run so far).

rakslice commented 4 years ago

Now that I think about it, I wasn't building with SDL2 in Debian 9, just the packaged SDL 1.2, because this fork although it has SDL2 support it isn't quite right -- it seems to have a random chance of a deadlock on launch with SDL2 which resembles one that is fixed in other forks

SegHaxx commented 4 years ago

Well for now I'm going to say no rush on this PR. :) SheepShaver is a basket case and is going to need some time and debugging to fix.

rakslice commented 4 years ago

Fair enough. If you ever run out of expectations that it is something it's not, whatever it is it will still be here.

SegHaxx commented 4 years ago

Okay tried it again and it seems to work this time. CentOS 8 x86_64 with SELinux disabled and the mmap limit off, built with real addressing and with JIT enabled will boot to a desktop with a System 7.6.1 install CD:

$ sestatus|grep Current
Current mode:                   permissive
$ cat /proc/sys/vm/mmap_min_addr 
0
$ ./SheepShaver 
SheepShaver V2.5 by Christian Bauer and Mar"c" Hellwig
mmap next=0x10000000 got=0x10000000
Reading ROM file...
Using SDL/pulseaudio audio output
selected Ethernet device type slirp
Using SDL_Renderer driver: opengl
mmap next=0x10080000 got=0x10080000
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
mmap next=0x1025d000 got=0x1025d000
mmap next=0x102dd000 got=0x102dd000

JIT disabled seems to give me the same crash at "Welcome to Mac OS" I get with direct addressing. So I think we're at least on the same page now. :)

rakslice commented 4 years ago

144 should fix that JIT disabled crash for both of those cases.

ianfixes commented 4 years ago

Thanks very much for contributing this!

Is there a test that can be added to demonstrate the fixed code as part of CI?

Also, does this need a corresponding documentation change as you indicated in the issue?

SegHaxx commented 4 years ago

Not sure what's documented right now, but no don't tell people to disable security features. The idea is a default build should just work without having to do anything special. My ulterior motive here is I'd like to see Basilisk II return to the Debian repositories and turning off security features is going to be a no-go there. And it looks like SheepShaver has never even been in Debian.

With BII/SS more widely available we might even attract more developers to fix things. :)

SegHaxx commented 4 years ago

The way forward is to fix SheepShaver JIT so it can run with direct addressing. rakslice are you working on that? :)

ianfixes commented 4 years ago

My ulterior motive is to see the build system and CI improved a bit... the build system is "artisanal" and the CI is mostly just compile tests at the moment. So I think we are working toward the same goal.

Should we open a separate issue to simply remove the "real addressing" code at a later point? What are the chances that it would be needed going forward?

SegHaxx commented 4 years ago

As this fork seems focused on current systems, once JIT works with direct addressing, real addressing could probably be entirely ripped out yes. Something for a future PR. :)

ianfixes commented 4 years ago

Please open issues for those tasks. I'm not trying to be lazy, I just don't think I can properly articulate the interaction between the JIT and the rest.

Besides that, @rakslice is this good to merge?

rakslice commented 4 years ago

The way forward is to fix SheepShaver JIT so it can run with direct addressing. rakslice are you working on that? :)

For the purposes of this pull request I presume what we want is to just disable the SheepShaver JIT on the platforms where it won't work because the addressing mode has changed and it doesn't match the pregenerated stuff. Am I working on that? No, I assumed you were going to do that as a change in this PR since it's just a configure script change, but I'll take a look.

Now, in the philosophical sense, I'm working on getting rid of the perpetual stumbling block of being stuck with a SheepShaver JIT with parts that can only be built with an ancient compiler, and if/when that gets done you would be able to just rebuild everything no matter the addressing mode or whatever other depended-on config options, but that's not based on this fork and needs a heck of a lot more testing, and probably rework in places to not be awful proof of concept experimental code.

As far as the half-way point of just trying to figure out whatever the current pregenerated stuff was built with, so we can rebuild it with that with different options, well, I was hoping someone would answer the question https://github.com/cebix/macemu/issues/222 before I had to go follow any more leads but I guess I can get back on that

ianfixes commented 3 years ago

I'm working on [something] that's not based on this fork and needs a heck of a lot more testing

If there's anything I can add to CI to surface the testing efforts (to prevent regressions in the future) please let me know

SegHaxx commented 3 years ago

Alright if SheepShaver JIT is definitely broken (with direct addressing) for now, disable it by default.

ianfixes commented 3 years ago

Which platforms is it broken on? Or what does "platform" indicate in this case?

SegHaxx commented 3 years ago

When I tear real addressing out of SheepShaver, JIT will be broken on all platforms. :)