Hello everyone, I'm developing a small open source utility to synchronise M3U playlists and associated media to devices such as network shares and USB devices. During testing though, it routinely crashes my machine. It appears that heavy SMB workloads on Monterey 12.5.1 and 12.4 eventually cause the kernel to completely hang, even when run as an unprivileged user. For reference, I am mounting an SMB3 share via Finder and using Python's shutils copy2 function to copy around 3000 ALAC files to a Synology NAS. This is on an M1 MacBook Pro with 16GB of RAM. The process starts well, but after about 20 minutes, the machine will become increasingly unresponsive. After 30 minutes, it will become completely unresponsive - even the touchbar and haptic feedback on the touchpad will be dead by then, requiring a complete cold boot to restore. Activity monitor and ps don't show anything out of the ordinary in terms of open file handles or memory usage, however the CPU usage of kernel_task steadily grows to around ~300%. If I can regain control of the system and stop the file copying process, eventually that figure will fall, but it takes around 10 minutes for the system to become stable again. In any event, it shouldn't be possible for a user task in userspace to completely destroy the system in this way, especially not doing something as benign as copying files. For the record, NFS works flawlessly, presumably because it's a robust and mature implementation vs Apple's implementation of SMB which has never really worked well in my experience. Has anyone else experienced anything similar? Is NFS the recommended protocol for people who don't want to brick their machine? Or should I just be using iCloud and Apple Music and give up with files?

Hi! I'm exploring options to prevent date tampering on my app. One of those options involves obtaining the uptime of the device using sys/sysctl.h which I understand is an approved and supported way to do for macOS but I'm not sure if it would be approved during an Apple Review for my iOS app. Does anyone know or have experience with this? Is it ok or will it get my app rejected? I leave my code as reference here: #include <sys/types.h> #include <sys/sysctl.h> + (time_t)uptime {     struct timeval boottime;     int mib[2] = {CTL_KERN, KERN_BOOTTIME};     size_t size = sizeof(boottime);     time_t now;     time_t uptime = -1;     (void)time(&now);     if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1 && boottime.tv_sec != 0) {         uptime = now - boottime.tv_sec;     }     return uptime; } Thanks for any help you could provide

I've seen a lot of people asking how to get 32 bit apps running again on newer versions of OSX, and mostly these just get answered with "sorry cant be done". Why? There must be a reason why it can't be done. From an OS perspective, its just libraries right? Why can't I make a kernel extension to enable 32-bit and get some 32-bit libraries? And what about the M1 processor -- did intel-based 32bit support work via some capabilities of the chip, which I presume the M1 would not include? Are there any references on whether the M1 on another OS could run 32-bit applications (like linux or BSD)? I've heard reports that Windows for ARM on M1 will run 32 bit apps (I haven't independently verified this). I'm really tired of seeing closed threads ending with "can't be done". Please put more effort in than that. I want a why and how.

Hi, I have a MacBook Pro M1 that I'm trying to boot development kernel. The SW version is: ProductName: macOS ProductVersion: 11.4 BuildVersion: 20F71 I follow /Library/Developer/KDKs/KDK_11.4_20F71.kdk/KDK_ReadMe.rtfd/TXT.rtf and disabled SIP and authenticated-root. I also copy over the kernels to a livemohnt and update nvram: nvram boot-args="-v kcsuffix=development" Despite above changes, after reboot, I still don't see the OS booting using development kernel (sysctl kern.osbuildconfig shows I'm still running release.) Anyone has any luck to enable development/debug/custom kernels on Big Sur?

I've used DB_KPRT to send IOLog, printf, and kprintf messages over serial port (115200 baud) to another Mac. If I try to do the same with FireWire, it appears that only kprintf messages are sent. Is there a boot arg that can change that? If not then what would have to be changed in xnu? A global variable or function or something? Is there another connection type such as USB or Ethernet that can send IOLog like the serial port can?

I send a Requesting a Developer ID Certificate for Signing Kexts. But there was no response in the past two months. How can I know the progress?

How should I get a certificate that allows me to develop kernel extensions?

Hello, I've run into an issue that for the newest macOS Big Sur 11.6.7 there is no Kernel Development Kit (KDK) available under: https://developer.apple.com/download/all/?q=kernel%20debug%20kit%2011.6.7 The latest possible KDK is for 11.6.5. However, the KDK's for 11.6.6 and 11.6.7 are missing. Could somebody please provide more information whether the missing KDK's will be avialable or not? It is necessary that the KDK matches the current kernel version, which means that using older KDK is not a solution. Best Regards abetz

I'm getting some Crash Reports for an app of mine that's on the Mac App Store. A few details: -All the crash reports are on ARM-64 Macs. -The call stack shows my app calling NSURL's -getResourceValue:forKey: method with NSURLLocalizedNameKey, which is the last call made by my app before the crash. After that crash logs look like this: **Thread 0 Crashed: 0   libobjc.A.dylib               0x00000001a623c4b0 objc_retain + 16 1   LaunchServices                0x00000001a6954f68 -[FSNode(PathAndName) nameWithError:] + 72 2   LaunchServices                0x00000001a6a36278 +[_LSDisplayNameConstructor(ConstructForAnyFile) displayNameConstructorWithContextIfNeeded:bundle:bundleClass:node:preferredLocalizations:error:] + 2732 3   LaunchServices                0x00000001a6a357ac +[_LSDisplayNameConstructor(ConstructForAnyFile) displayNameConstructorWithContextIfNeeded:node:error:] + 44 4   LaunchServices                0x00000001a6ae5b20 LaunchServices::URLPropertyProvider::getDisplayNameConstructor(LaunchServices::Database::Context&, FSNode*, LaunchServices::URLPropertyProvider::State*, NSError* __autoreleasing*) + 88 5   LaunchServices                0x00000001a6ae1930 LaunchServices::URLPropertyProvider::prepareLocalizedNameValue(LaunchServices::Database::Context&, FSNode*, __FileCache*, __CFString const*, LaunchServices::URLPropertyProvider::State*, NSError* __autoreleasing*) + 328 6   LaunchServices                0x00000001a6953d6c LaunchServices::URLPropertyProvider::prepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 456 7   CoreServicesInternal          0x00000001a8def6f0 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 452 8   CoreServicesInternal          0x00000001a8dec5ec _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) + 236 9   CoreFoundation                0x00000001a64546b0 CFURLCopyResourcePropertyForKey + 144 10  CoreFoundation                0x00000001a646b944 -[NSURL getResourceValue:forKey:error:] + 120** -- I haven't been able to reproduce the issue on my ARM-64 Mac. Not sure what's going with _LSDisplayNameConstructor or if there is a way I can workaround/resolve. Some of the crashes have the following lines included: Kernel Triage: VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get

We have some extensive tests which exercise UDP communication. Some of these tests fail fairly often due to the UDP packet being dropped by the kernel (or related reasons). These tests use loopback interface for communication. I have been looking to see if there's a way to pinpoint or narrow down exactly why a particular packet was dropped by the kernel. Looking at the kernel code, like here https://github.com/apple-opensource/xnu/blob/master/bsd/netinet/udp_usrreq.c#L1463 it appears that there are log message that get written out during some of this communication. However, looking at what KERNEL_DEBUG stands for, it appears that it's: /* * Traced only on debug kernels. */ #define KDBG_DEBUG(x, ...) KDBG_(_DEBUG, x, ## __VA_ARGS__, 4, 3, 2, 1, 0) So I don't think these logs get generated in a regular release build of the OS. Are there any other ways we can generate similar logs or any other tools that will give a clearer picture of why the packet might be drop?

Even when SIP is disabled. It shows an error, and dumps the dtrace script to console! Used to work fine until BigSur.

Hi! I am a bit baffled by the current state of dtrace. Usual probes like syscall are not present by default on Apple Silicon, and dtruss and countless other utilities do not work, even with SIP disabled and Permissive Security. A precedent thread (https://developer.apple.com/forums/thread/692444) mentioning execsnoop was answered by mentioning the Kernel Debug Kit. It is not clear to me what the KDKs provide that could make dtrace work again. If the intention is installing alternative kernels (development/kasan), those are not supported in Apple Silicon. I know there are other ways of tracing the kernel but I'd like to know if officially dtrace is just legacy and unsupported or if there is actually a way to make it work. I need to examine some xnu memory structures and it's exhausting to not even know if I can use dtrace or not.

Hello, I am seeing below error message while unloading the kernel extension (kext) using kmutil command: Daemon is not reachable - operating in standalone mode. Only kexts contained in the boot kernel collection will be unloadable. kext seems to be in "auxiliary kext collection" and system is expecting to be in "boot kext collection". Any idea what can be done to do so?

Hi, I'm looking for a developer to update a currently Intel-only legacy kext into a system extension so it works on M1 / ARM / Apple Silicon. Here's the problem: I'm a heavy user of a legacy software named ControllerMate. Unfortunately, it has been abandoned by the developer and he didn't make it open-source. The latest update was in late 2018 and the developer has stopped responding entirely and can not be reached, even to previous beta-testers. Confirmed by several power users who tried over the years. The app basically allows creation of macros and cascades and is extremely powerful. It's used by many people in the video post production and music production space in their professional workflows, and people built individual workflows around this over the years to work faster and more efficiently. Since it hasn't been updated, people are somewhat stuck and can't upgrade without breaking their workflows. Especially now with the new and powerful M1s, this becomes much more urgent and relevant again. The kext might have to be reverse engineered or hacked - I know, not something people in an Apple developer forum wanna hear, but we're desperate to find somebody for this and keep this going. I truly appreciate any input, insights and leads! Thank you!

Copied from the apple community discussions where my post was removed, but this is about kernel panic see my kernel panic string below. "Some more information because I'm bored and as software engineer want to debug the issue to its root cause. This should determine if it is truly a hardware issue or some horrible code that was pushed to production whether by apple directly or an individual app causing the issue. 15.4.1 after update phone restarts with kernel panic. Wifi is spotty, device can't stay without booting long enough to install the 15.5 beta software, (thanks for unlimited data otherwise lol goodluck because I tried this step probably 10 times) Did a network reset -> Same issue.. Full reset -> Restore from backup -> Same issue... Full reset -> Do NOT restore from backup. -> Skip wifi entry/selection during initial setup. -> Was able to download and install 15.5. Boot into 15.5 Connect to wifi -- no issues 100% stable. --> so its not hardware (surprise surprise) --> Now to determine what is causing the issue, will restore my backup. If the device does not return to crashing, it is the 15.4.1 IOS/kernel. If it does start crashing again It should be 100% app related. What app in particular I won't determine, but I still would still 100% blame apple for allowing an app trying to use wifi to cause kernel panic). I will add another reply once I have determined this." Update Restored backup while on 15.5 ios, and issue started again. So should be individual app or possibly stored setting. I suppose last step is to manually restore apps 1 at a time to see individual cause. I guess I will slowly do this as I would like my apps back while keeping my phone useable. Kernel panic string: `"panicString" : "panic(cpu 0 caller 0xfffffff00df61e18): userspace watchdog timeout: no successful checkins from wifid in 180 seconds\nservice: backboardd, total successful checkins since wake (1260 seconds ago): 127, last successful checkin: 0 seconds ago\nservice: SpringBoard, total successful checkins since wake (1260 seconds ago): 127, last successful checkin: 0 seconds ago\nservice: mediaserverd, total successful checkins since wake (1260 seconds ago): 127, last successful checkin: 0 seconds ago\nservice: logd, total successful checkins since wake (1260 seconds ago): 127, last successful checkin: 0 seconds ago\nservice: thermalmonitord, total successful checkins since wake (1260 seconds ago): 126, last successful checkin: 0 seconds ago\nservice: runningboardd, total successful checkins since wake (1260 seconds ago): 127, last successful checkin: 0 seconds ago\nservice: wifid, total successful checkins since wake (1260 seconds ago): 109, last successful checkin: 180 seconds ago\n\nDebugger message: panic\nMemory ID: 0x1\nOS release type: User\nOS version: 19E258\nKernel version: Darwin Kernel Version 21.4.0: Mon Feb 21 21:27:55 PST 2022; root:xnu-8020.102.3~1/RELEASE_ARM64_T8101\nKernel UUID: C5AD4894-FB9D-3230-8B28-039D8ABD26C7\niBoot version: iBoot-7459.102.5\nsecure boot?: YES\nPaniclog version: 13\nKernel slide: 0x0000000004484000\nKernel text base: 0xfffffff00b488000\nmach_absolute_time: 0x7886bc109\nEpoch Time: sec usec\n Boot : 0x6259f2d0 0x0008e55f\n Sleep : 0x6259f663 0x00047875\n Wake : 0x6259f73f 0x000870d3\n Calendar: 0x6259fc2b 0x000cd48a\n\nZone info:\n Foreign : 0xfffffff1b4f64000 - 0xfffffff1b4f74000\n Native : 0xffffffe000790000 - 0xffffffe600790000\n Readonly: 0xffffffe0e6df4000 - 0xffffffe133ac0000\n Metadata: 0xffffffeb0493c000 - 0xffffffeb09010000\n Bitmaps : 0xffffffeb0613c000 - 0xffffffeb081f8000\n\nCORE 0 recently retired instr at 0xfffffff00c107db8\nCORE 1 recently retired instr at 0xfffffff00c109228\nCORE 2 recently retired instr at 0xfffffff00c109228\nCORE 3 recently retired instr at 0xfffffff00c109228\nCORE 4 recently retired instr at 0xfffffff00c10922c\nCORE 5 recently retired instr at 0xfffffff00c10922c\nCORE 0 is the one that panicked. Check the full backtrace for details.\nCORE 1: PC=0x00000001d2ccbda0, LR=0x00000001d2cdf13c, FP=0x000000016f636830\nCORE 2: PC=0x00000001d2cee6dc, LR=0x00000001d2ccb2a8, FP=0x000000016cf3ea10\nCORE 3: PC=0x000000024389bc80, LR=0x0000000107cfd800, FP=0x000000016f5deb30\nCORE 4: PC=0xfffffff00bff4b00, LR=0xfffffff00bff4b00, FP=0xffffffeb11173f00\nCORE 5: PC=0xfffffff00bff4b00, LR=0xfffffff00bff4b00, FP=0xffffffeb11183f00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nTotal cpu_usage: 47205302\nThread task pri cpu_usage\n0xffffffe2fff13090 watchdogd 97 0\n0xffffffe2feda69a0 runningboardd 37 0\n0xffffffe2ff7b8000 watchdogd 31 0\n0xffffffe2fff2f780 com.apple.Mobile 4 3398193\n0xffffffe2fed83780 com.apple.Mobile 4 3835978\n\nPanicked task 0xffffffe133b21350: 275 pages, 3 threads: pid 60: watchdogd\nPanicked thread: 0xffffffe2fff13090, backtrace: 0xffffffeb110931c0, tid: 1727\n\t\t lr: 0xfffffff00bfc0af0 fp: 0xffffffeb11093200\n\t\t lr: 0xfffffff00bfc0808 fp: 0xffffffeb11093270\n\t\t lr: 0xfffffff00c10fb24 fp: 0xffffffeb11093290\n\t\t lr: 0xfffffff00c100a28 fp: 0xffffffeb11093300\n\t\t lr: 0xfffffff00c0ff6fc fp: 0xffffffeb110933c0\n\t\t lr: 0xfffffff00c70f728 fp: 0xffffffeb110933d0\n\t\t lr: 0xfffffff00bfc04e4 fp: 0xffffffeb11093760\n\t\t lr: 0xfffffff00bfc04e4 fp: 0xffffffeb110937c0\n\t\t lr: 0xfffffff00e0894a4 fp: 0xffffffeb110937e0\n\t\t lr: 0xfffffff00df61e18 fp: 0xffffffeb11093800\n\t\t lr: 0xfffffff00df61720 fp: 0xffffffeb11093820\n\t\t lr: 0xfffffff00df60a14 fp: 0xffffffeb11093940\n\t\t lr: 0xfffffff00c67cb60 fp: 0xffffffeb11093ad0\n\t\t lr: 0xfffffff00c0cc4c8 fp: 0xffffffeb11093bf0\n\t\t lr: 0xfffffff00bfc7b24 fp: 0xffffffeb11093c90\n\t\t lr: 0xfffffff00bf95518 fp: 0xffffffeb11093cf0\n\t\t lr: 0xfffffff00bfb04c4 fp: 0xffffffeb11093d80\n\t\t lr: 0xfffffff00c0f4104 fp: 0xffffffeb11093e50\n\t\t lr: 0xfffffff00c0ffb2c fp: 0xffffffeb11093f10\n\t\t lr: 0xfffffff00c70f728 fp: 0xffffffeb11093f20\n\n",

i use lldb debug kernel find this error: lldb version: lldb-1300.0.42.3 Swift version 5.5.2-dev i can not continue to use lldb to debug: (lldb) settings set target.load-script-from-symbol-file true ############################## WARNING! Python version 3 is not supported for xnu lldbmacros. Please restart your debugging session with the following workaround This LLDB cannot debug kernel. Check KDK documentation. ############################## how to solve this problem?

Is it allowed for binaries to be signed with custom entitlements (e.g. com.flagers.xyz) for the purposes of determining the authenticity of an application using IOServiceOpen.

I have just installed the latest Xcode (13.3.1) and am finding that when I attempt to build a kernel extension (which was compiling fine in 13.2.1) I encounter the following error:  error: use of undeclared identifier '__APPLE_CC__' This appears to be inside an auto-generated file named <TargetName>_info.c, located in ../Intermediates.noindex/<ProjectName>.build/Debug/<TargetName>.build/DerivedSources/ I couldn't see any reference to this change in the release notes for Xcode 13.3 or 13.3.1. From some reading it appears that __APPLE_CC__ is related to a C compiler version. Has anyone else encountered this or know whether this is a bug, or part of the deprecation of kernel extensions? Many thanks

I'm trying to hint the task scheduler that some threads should be scheduled together using the task_policy_set API with THREAD_AFFINITY_POLICY (in lieu of there being no "real" thread to core affinity API). All the examples mention setting the policy after creation but before execution of the task(s). Unfortunately, I'm not creating these tasks (but OpenMP is), and when I then try to use the API on an already running thread, I get a return value of KERN_INVALID_ARGUMENT(= 4) thread_affinity_policy_data_t policy = { 1 }; auto r = thread_policy_set(mach_task_self(), THREAD_AFFINITY_POLICY, (thread_policy_t)&amp;policy, THREAD_AFFINITY_POLICY_COUNT); When I replace mach_task_self() by pthread_mach_thread_np(pthread_self()), I get an KERN_NOT_SUPPORTED error instead (= 46, "Empty thread activation (No thread linked to it)"). Has anyone used these APIs successfully on an already running thread? Background: The code I'm working on divides a problem set into a small number of roughly equal sized pieces (e.g. 8 or 16, this is an input parameter derived from the number of cores to be utilized). These pieces are not entirely independent but need to be processed in lock-step (as occasionally data from neighboring pieces is accessed). Sometimes when a neighboring piece isn't ready yet for a fairly long time, we call std::this_thread::yield() which unfortunately seems to indicate to the scheduler that this thread should move to the efficiency cores (which then wreaks havoc with the assumption of each computation over a piece roughly requiring the same amount of time so all threads can remain in lock-step). :( A similar (?) problem seems to happen with OpenMP barriers, which have terrible performance on the M1 Ultra at least unless KMP_USE_YIELD=0 is used (for the OpenMP run-time from LLVM). Can this automatic migration (note: not the relinquishing of the remaining time-slice) be prevented?

Hi, I'd to re-sign an app with an embedded kernel extension. The primary reason for it is that the author of the extension has not signed the binary with timestamp ("The signature does not include a secure timestamp.") as such the app fails the notarisation process. Sadly, I cannot find any way in the Developer Program admin panel to generate a certificate with kernel extensions support. What's the process of generating this certificate? Many thanks for help