Macos: add highly experimental sandboxing, add testing entitlements

[n30f0x]

Compile with USE_DEBUG and USE_EXPERIMENTAL_SHIT flags to

[LekKit]

I don't think thread isolation could work on Mac OS, so please keep restrict_this_thread() untouched (Or I may remove it later).

Otherwise it's looking OK.

[n30f0x]

I propose to leave it as is, it may be possible to sandbox threads among the main process.
Main problem lies in fact that rvvm gui is a secondary thread and with sandbox applied results in crash. Looking forward to resolve it.

[n30f0x]

Finally fixed, please review again

[polina4096]

Everything seems to be working really well on my M3 Max 14c 30g 36GB MacBook Pro, on macOS 15.3 Beta (sequoia). Activity monitor shows that the process is sandboxed, no network issues.

The only issues I faced while testing were sudden random crashes on startup. Starting with --no-gui flag disables the GUI, but the crashes on startup are gone.

Output

INFO: Attached MMIO device at 0x02000000, type "aclint_mswi"
INFO: Attached MMIO device at 0x02004000, type "aclint_mtimer"
INFO: Attached MMIO device at 0x0c000000, type "plic"
INFO: Attached MMIO device at 0x30000000, type "pci_bus"
INFO: Attached MMIO device at 0x10030000, type "i2c_opencores"
INFO: Attached MMIO device at 0x00101000, type "rtc_goldfish"
INFO: Attached MMIO device at 0x00100000, type "syscon"
INFO: Attached MMIO device at 0x10000000, type "ns16550a"
INFO: Raising RLIMIT_NOFILE to 4294967295
INFO: Attached MMIO device at 0x40000000, type "rtl8169"
INFO: Attached MMIO device at 0x40004000, type "nvme"
INFO: Attached MMIO device at 0x00000000, type "gui_window"
INFO: Attached MMIO device at 0x28000000, type "framebuffer"
INFO: Generated DTB at 0x27fffcd70, size 12940
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x128808200 started
DEBUG: We hit thread #67584 sandboxing stage...
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x12880ba00 started
INFO: Hart 0x128819a00 started
DEBUG: We hit thread #67584 sandboxing stage...
DEBUG: We hit thread #67584 sandboxing stage...
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x128820a00 started
DEBUG: We hit thread #67584 sandboxing stage...
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x12881d200 started
DEBUG: We hit process sandboxing stage...
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x128824200 started
INFO: Hart 0x12880f200 started
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x12882ea00 started
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x12882b200 started
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x128835a00 started
INFO: Hart 0x128827a00 started
DEBUG: We hit thread #67584 sandboxing stage...
WARN: Legacy isolation used, may not work in newer versions!
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x128832200 started
DEBUG: We hit thread #67584 sandboxing stage...
INFO: Hart 0x128816200 started
INFO: Hart 0x128812a00 started
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000018b30ae80 __exceptionPreprocess + 176
	1   libobjc.A.dylib                     0x000000018adf2cd8 objc_exception_throw + 88
	2   AppKit                              0x000000018f774094 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3072
	3   libSDL2-2.0.0.dylib                 0x00000001014685c0 Cocoa_PumpEventsUntilDate + 84
	4   libSDL2-2.0.0.dylib                 0x0000000101468770 Cocoa_PumpEvents + 56
	5   libSDL2-2.0.0.dylib                 0x00000001013e51d8 SDL_PumpEventsInternal + 64
	6   libSDL2-2.0.0.dylib                 0x00000001013e52f0 SDL_WaitEventTimeout_REAL + 88
	7   rvvm_arm64                          0x000000010100a5d8 sdl_window_poll + 80
	8   rvvm_arm64                          0x0000000100ff48f4 gui_window_update + 32
	9   rvvm_arm64                          0x0000000100fed1ec rvvm_eventloop + 1208
	10  libsystem_pthread.dylib             0x000000018b1b02e4 _pthread_start + 136
	11  libsystem_pthread.dylib             0x000000018b1ab0fc thread_start + 8
)
libc++abi: terminating due to uncaught exception of type NSException
zsh: abort      ./rvvm_arm64 fw_payload.bin -i archriscv.img -m 8G -v -thread -s 14 -res

[LekKit]

The event loop (Which also happens to handle GUI/Serial console) bounces between threads upon startup, and finally runs on the main thread in the long term, yet the OSX cocoa subsystem has highly specific requirements that it must run on the main thread and the initial "bouncing" causes a race condition inside cocoa and a crash.

This was never an issue on other platforms, but the assumption about being able to run OS-specific code on any thread perhaps no longer applies