I am unsure if there has been any progress in this area. But I needed to resolve a recent Tahoe panic, so chatgpt cobbled together this: https://gist.github.com/lundman/54e633a850e7623aae5adab38a39f464 If we are allowed to share? Either way, output was: ./symbolicate_panic.py -p ~/ZFS.2.3.1rc1.kernel.panic.-.Tahoe.M4.Pro.Mac.Mini.txt -k /Library/Extensions/zfs.kext/Contents/MacOS/zfs --kernel --kdk-nearest --accept-mismatch === KEXT mapping === bundle: org.openzfsonosx.zfs arch: arm64e base@: 0xfffffe004400d840 file __TEXT vmaddr: 0x0 file __TEXT_EXEC vmaddr: 0x70000 delta=0x70000 chosen TEXT_LOAD: 0xfffffe0043f9d840 === Kernel mapping (via KDK) === checking for KDK build 25A354 ... nearest: /Library/Developer/KDKs/KDK_26.0_25A353.kdk build: 25A354 SoC: t6041 kernel: /Library/Developer/KDKs/KDK_26.0_25A353.kdk/System/Library/Kernels/kernel.release.t6041 panic Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 KDK Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 file __TEXT vmaddr: 0xfffffe0007004000 file __TEXT_EXEC vmaddr: 0xfffffe00072cc000 delta=0x2c8000 panic Kernel text exec base: 0xfffffe003e2c4000 chosen TEXT_LOAD: 0xfffffe003dffc000 ESR: 0x96000005 -> Data Abort, same EL; Translation fault, level 1 FAR: 0x0000000000000084 === Panicked thread (merged, ordered) === 0xfffffe004401d934 [zfs] taskq_dispatch (in zfs) (spl-taskq.c:1457) 0xfffffe003e3164c0 [kernel] handle_debugger_trap (in kernel.release.t6041) (debug.c:1863) 0xfffffe003e48bc54 [kernel] handle_uncategorized (in kernel.release.t6041) (sleh.c:1818) 0xfffffe003e489e8c [kernel] sleh_synchronous (in kernel.release.t6041) (sleh.c:0) 0xfffffe003e2c7d48 [kernel] fleh_synchronous (in kernel.release.t6041) + 72 0xfffffe003e3167d0 [kernel] DebuggerTrapWithState (in kernel.release.t6041) (debug.c:830) 0xfffffe003ec199c8 [kernel] Assert (in kernel.release.t6041) (debug.c:841) 0xfffffe003ec24c74 [kernel] sleh_synchronous_sp1 (in kernel.release.t6041) (sleh.c:1191) 0xfffffe003e48bac4 [kernel] handle_kernel_abort (in kernel.release.t6041) (sleh.c:3960) 0xfffffe003e489ed0 [kernel] sleh_synchronous (in kernel.release.t6041) (sleh.c:1544) 0xfffffe0044155ab4 [zfs] vdev_disk_io_start (in zfs) (vdev_disk.c:750) 0xfffffe0044140c54 [zfs] zio_vdev_io_start (in zfs) (zio.c:0) 0xfffffe004413bdd8 [zfs] zio_nowait (in zfs) (zio.c:2580) 0xfffffe00440dbb98 [zfs] vdev_probe (in zfs) (vdev.c:1840) 0xfffffe00440dc92c [zfs] vdev_open (in zfs) (vdev.c:2273) 0xfffffe00440e4d90 [zfs] vdev_open_child (in zfs) (vdev.c:1868) 0xfffffe004401ffe4 [zfs] taskq_thread (in zfs) (spl-taskq.c:2144) 0xfffffe0044020574 [zfs] spl_thread_setup (in zfs) (spl-thread.c:128) 0xfffffe003e2c87cc [kernel] Call_continuation (in kernel.release.t6041) + 204 Maybe it will help someone, or, if there is an official way now, please let me know.

OK, so wait, now is not the time. Thanks Quinn.

Cooked together a "notarytool" replacement that will do the work for me, and the build environment can remain the same. Instead of calling "xcrun notarytool" I run this: https://gist.github.com/lundman/9166dc8bef1973e5d9fc5428e0cedc57 Nothing special, but might save someone a few minutes having to do it themselves.

Same here, 10.14 and 10.15 both need to be notarized. With 10.15 I can copy the notarytool from Monterey's xcode (13.1), and it runs fine. With 10.14 it does not run due to: dyld: Library not loaded: /System/Library/Frameworks/CryptoKit.framework/Versions/A/CryptoKit If I copy over a local copy of CryptoKit, I can not set DYLD_LIBRARY_PATH anymore, sad-face. Possibly I could strip it of the codesign certificate and add "com.apple.security.cs.allow-dyld-environment-variables" but that feels like I'm close to yak shaving. 10.13 does not need notarizing, so it is odd Apple left one OS out in the cold. Has anyone come up with a solution that doesn't require me to copy it to a 2nd VM running newer macOS?

Word is that there now is a work-around, if somewhat complicated. I suspect with a bit more time, it will be streamlined down to something nicer.

This is still an issue, including on the sonoma release. Snapshot API calls are there, but the ability to load kexts is still missing.

Possibly it can be done, but I went to beta3 instead, which has a matching KDK.

To be complete, this is what we went with: #if defined(__aarch64__) uint64_t mpidr_el1; asm volatile("mrs %0, mpidr_el1" : "=r" (mpidr_el1)); /* * To save us looking up number of eCores and pCores, we * just wrap eCores backwards from max_ncpu. * 0: [P0 P1 P2 ... Px Ex .. E2 E1 E0] : max_ncpu * * XNU: Aff2: "1" - PCORE, "0" - ECORE */ #define PCORE_BIT (1ULL << 16) if (mpidr_el1 & PCORE_BIT) return ((uint32_t)mpidr_el1 & 0xff); else return ((max_ncpus -1) - (uint32_t)(mpidr_el1 & 0xff)); #else return ((uint32_t)cpu_number()); #endif }

uint32_t getcpuid(void) { #if defined(__aarch64__) uint64_t mpidr_el1; asm volatile("mrs %0, mpidr_el1" : "=r" (mpidr_el1)); return (uint8_t)(mpidr_el1 & 0xff); #else return ((uint32_t)cpu_number()); #endif } Is a start, on my 8core M2, it returns values 0x00 to 0x03 from Aff0 bits. Generally the 4 fast cores. If you idle for a bit, you can probably look at the Aff1 (cluster) values, returning values like 0x0102 - which probably means the slower cores. But for the sake of reducing contention by spreading out locks over cores, this is a good start.

With exhaustive printf debugging - since this is now the best available, we found out the old line: static char initial_default_block[16ULL*1024ULL*1024ULL] __attribute__((aligned(16384))) = { 0 }; Used to bootstrap our memory allocator, would not work on Ventura+M1+more-than-16GB ram. Ie, MacStudio 128G. Monterey on same hardware (As well as all lower M1s, and x86_64) are fine. We replaced it with: initial_default_block = IOMallocAligned(INITIAL_BLOCK_SIZE, 16384); memset(initial_default_block, 0, INITIAL_BLOCK_SIZE); Unlikely anyone else would bump into this issue, but it feels more complete to post the answer.

Maybe you could write a program that will dlopen() and 32bit app, the intercept any interlibrary calls, libc, syscall, with glue to translate 32bit to 64bit and back. It would be a massive undertaking, with no guarantee that you wouldn't hit a brick wall at somepoint.. .. when all "they'd" have to do is compile it for 64 bit :) Might even be easier to go translate the 32bit assembler to 64bit in each segment. But that does nothing to help you with the "old" API calls, you'd still need to interpose them with glue.

The KDK readme says: Note: Apple silicon doesn’t support installing the kernel and kernel extension variants from the KDK. So I think you just can't, even now, three major versions later.

OK, dtracing the debug kernel helped here, as certain functions were not inlined: dtrace -n 'mac*:entry / execname == "nfsd" / {} ' -n 'mac*:return / execname == "nfsd" / { printf("%d %s", arg1, execname); }' -n 'nfs*:entry / execname == "nfsd" / {} ' -n 'nfs*:return / execname == "nfsd" / { printf("%d %s", arg1, execname); }' -n 'vnode*:entry / execname == "nfsd" / {} ' -n 'vnode*:return / execname == "nfsd" / { printf("%d %s", arg1, execname); }' -n 'vn*:entry / execname == "nfsd" / {} ' -n 'vn*:return / execname == "nfsd" / { printf("%d %s", arg1, execname); }' -n 'nfsrv_rephead:entry { nd = arg0 + 0x88; tracemem(nd, 4); printf("rephead %d", arg0);}' Yeah, the whole thing. Anyway, it produced this hint: 1 269114 mac_vnode_check_open:entry 1 269042 mac_cred_check_enforce:entry 1 269043 mac_cred_check_enforce:return 1 nfsd 1 232364 vn_getpath_ext_with_mntlen:entry 1 231850 build_path_with_parent:return 2 nfsd 1 232365 vn_getpath_ext_with_mntlen:return 2 nfsd 1 232364 vn_getpath_ext_with_mntlen:entry 1 231850 build_path_with_parent:return 2 nfsd 1 232365 vn_getpath_ext_with_mntlen:return 2 nfsd 1 268848 mac_error_select:entry 1 268849 mac_error_select:return 2 nfsd 1 269115 mac_vnode_check_open:return 2 nfsd ie, it's not that mac_vnode_check_open() but rather that vn_getpath_ext_with_mntlen() fails. (Technically, build_path_with_parent()). At the end of my zfs_vnop_create() - if I add the call: vnode_update_identity(*ap->a_vpp, NULL, (const char *)ap->a_cnp->cn_nameptr, ap->a_cnp->cn_namelen, 0, VNODE_UPDATE_NAME); I get a successful test run using O_EXCL over nfs, finally. I am not entirely sure why this is required, only place I call vnode_update_identity() is in vfs_vget(). Otherwise, I've "been getting away" with not calling it all this time. I assume it doesn't hurt to call it.

I'd be happy to not know it, if you know what I mean. But since NFS+O_EXCL isn't working right here, and yet, is working correctly with HFS, I just don't see why yet. HFS does have a handful of vnode_authorize() calls, of which I have zero. That is my current thinking anyway. There is a bunch of debug stuff in MAC, is it trivial to turn on to perhaps see why it complains? Running kernel.debug 10.15.7 Thanks for replying,

Running kernel.debug and dtrace - it looks like: 1 1 nfsrv_setattr:entry 1 1 mac_vnode_check_open:entry 1 1 mac_cred_check_enforce:return 1 nfsd 1 1 mac_label_get:return 0 nfsd 1 1 mac_error_select:return 2 nfsd 1 1 mac_error_select:return 2 nfsd 1 1 mac_error_select:return 2 nfsd 1 1 mac_policy_list_conditional_busy:return 0 nfsd 1 1 kernel.debug`nfssvc_nfsd+0x108b kernel.debug`nfssvc+0x360 kernel.debug`unix_syscall64+0x81f kernel.debug`hndl_unix_scall64+0x16 1 1 mac_vnode_check_open:return 2 nfsd 1 1 nfsrv_rephead:entry 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 0: 46 00 00 00 F... Which makes me thing that after the call to mac_label_get() it checks something and is not happy. I have not really looked into what vnode_label is but presumably has something to do with auth.