The amr64 panic logs are new and a bit different, has a whole bunch of information which is nice but, sometimes I get something like: panic(cpu 11 caller 0xfffffe0013d81f1c): Kernel data abort. at pc 0xfffffe001512adb4, lr 0xfffffe001512ad9c Debugger message: panic\n Memory ID: 0x6\n OS release type: User\n OS version: 21G115\n Kernel version: Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2\/RELEASE_ARM64_T6000\n Fileset Kernelcache UUID: 39A7E336B0FAA0022B3764E49DFF29D2\n Kernel UUID: 778CC57A-CF0B-3D35-8EE8-5035142D0177\ni Boot version: iBoot-7459.141.1\n secure boot?: YES\n Paniclog version: 13\n KernelCache slide: 0x000000000bc48000\n KernelCache base: 0xfffffe0012c4c000\n Kernel slide: 0x000000000c40c000\n Kernel text base: 0xfffffe0013410000\n Kernel text exec slide: 0x000000000c4f4000\n Kernel text exec base: 0xfffffe00134f8000 ktrace: 0xfffffe180eaaea80, tid: 144477\n\t\t lr: 0xfffffe0013551400 fp: 0xfffffe180eaaeaf0\n\t\t lr: 0xfffffe00135510c8 fp: 0xfffffe180eaaeb60\n\t\t lr: 0xfffffe001369733c fp: 0xfffffe180eaaeb80\n\t\t lr: 0xfffffe00136890cc fp: 0xfffffe180eaaebf0\n\t\t lr: 0xfffffe0013686cb0 fp: 0xfffffe180eaaecb0\n\t\t lr: 0xfffffe00134ff7f8 fp: 0xfffffe180eaaecc0\n\t\t lr: 0xfffffe0013550d4c fp: 0xfffffe180eaaf060\n\t\t lr: 0xfffffe0013550d4c fp: 0xfffffe180eaaf0d0\n\t\t lr: 0xfffffe0013d7954c fp: 0xfffffe180eaaf0f0\n\t\t lr: 0xfffffe0013d81f1c fp: 0xfffffe180eaaf270\n\t\t lr: 0xfffffe0013688ecc fp: 0xfffffe180eaaf2e0\n\t\t lr: 0xfffffe0013686fb4 fp: 0xfffffe180eaaf3a0\n\t\t lr: 0xfffffe00134ff7f8 fp: 0xfffffe180eaaf3b0\n\t\t lr: 0xfffffe001512ad9c fp: 0xfffffe180eaaf740\n\t\t lr: 0xfffffe001515ac20 fp: 0xfffffe180eaaf7a0\n\t\t lr: 0xfffffe001511a03c fp: 0xfffffe180eaaf9a0\n\t\t lr: 0xfffffe001511dc78 fp: 0xfffffe180eaafa10\n\t\t lr: 0xfffffe0015148d14 fp: 0xfffffe180eaafa40\n\t\t lr: 0xfffffe00137b8b24 fp: 0xfffffe180eaafad0\n\t\t lr: 0xfffffe0015145c4c fp: 0xfffffe180eaafce0\n\t\t lr: 0xfffffe00137cc864 fp: 0xfffffe180eaafd20\n\t\t lr: 0xfffffe00137b88c8 fp: 0xfffffe180eaafda0\n\t\t lr: 0xfffffe00137cc7ac fp: 0xfffffe180eaafdb0\n\t\t lr: 0xfffffe0013bbaa28 fp: 0xfffffe180eaafe50\n\t\t lr: 0xfffffe0013686d84 fp: 0xfffffe180eaaff10\n\t\t lr: 0xfffffe00134ff7f8 fp: 0xfffffe180eaaff20\n Kernel Extensions in backtrace:\n com.apple.filesystems.hfs.kext(583.100.10)[45F25204-8A60-3A88-B71F-974BDDBDB3BF]@0xfffffe00151148a0->0xfffffe00151634e3\n dependency: com.apple.filesystems.hfs.encodings.kext(1)[4183166A-286A-3CEB-8C2C-AF85AA1F4D16]@0xfffffe00151634f0->0xfffffe001516441f\n\n last started kext at 3074954554: com.apple.filesystems.smbfs\t4.0 (addr 0xfffffe00133f4c30, size 65195)\n loaded kexts:\n org.openzfsonosx.zfs\t2.1.99\n com.apple.filesystems.smbfs\t So if you are really lucky, it will list the address of your kext here, in this case, just com.apple.filesystems.hfs.kext. But nearly all the time, you have no way to get the load address for org.openzfsonosx.zfs, which I think means I can not lookup symbols, or anything useful at all. I think HFS called into ZFS and we returned something cursed. Would it be possible to have the load addresses listed in the large list of kext loaded?

Hello, we have developed a kernel extension (KEXT) for a virtual file system (VFS) to integrate our software with external programs like Adobe InDesign or Microsoft Word. Our software and the KEXT are used by many of our customers. As it looks like KEXTs are deprecated and may be removed completely in future versions of macOS, particularly on Apple Silicon based computers. See e.g. Apple's announcement in its security guide: "This is why developers are being strongly encouraged to adopt system extensions before kext support is removed from macOS for future Mac computers with Apple silicon" Therefore we are currently investigating in possible alternatives. Apple suggests to migrate to System Extensions instead of KEXTs. However, the only VFS related API we found is to implement a File Provider that is based on an NSFileProviderReplicatedExtension. Unfortunately that NSFileProviderReplicatedExtension has several flaws: Files can either be in the cloud or downloaded. It is not possible to download/read only a portion of a file. This is a big performance problem for us, since we work with large images (> 1GB). The programs we integrate with typically only read a part of the image, e.g. the embedded preview. The API does not offer a way to access selected blocks of a file (random access file). The File Provider learns about the file system content via enumerators. So everything that is inside a folder must be enumerated (listed) first. Otherwise it cannot be accessed. However, we cannot enumerate our VFS. Most of the content of our VFS is fully dynamic. It only exists when it is accessed by a client the first time. Such dynamic content also includes dynamic parameters like the client's locale or the size of a box where the image will be placed. Since we do not know those parameters in advance, we cannot enumerate the VFS's content in advance. This means, an NSFileProviderReplicatedExtension in its current state isn't a replacement for a "real" VFS and therefore cannot be used by us as a replacement for our current VFS KEXT. My questions: Will Apple allow kernel extensions also in future versions of (Apple Silicon/M1 based) operating systems? Or is there at least a clear deadline? If not, what is Apple's officially suggested replacement for KEXT based VFS solutions? Will the API of an NSFileProviderReplicatedExtension be improved to behave like a "real" file system so that above mentioned flaws will no longer be an issue? Many thanks for any answers or comments! Best regards, Michael

MacBook Pro 13.3" - Y4QVXL9FGW M2 8-core 24GB Unified memory 1T Solid Disk MacOS 12.5.1 (21G83) The screen flash pink and restarted again. No kernel crash log or warning anyhow.

I'm wondering if anyone has done any work to make using Kernel headers inside Dtrace scripts possible when using its functionality to run the preprocessor over a D script. AFAICT, D's compiler won't compile clang built-ins, inline functions or extern "C" declarations, C++ constructs, etc. Thanks in advance.

I'm trying to get the memory usage of the entire system. // referance: https://www.jb51.cc/iOS/590624.html public func memsize() -> UInt64 {     var taskInfo = mach_task_basic_info()     var count = UInt32(MemoryLayout<mach_task_basic_info>.size)     let kerr: kern_return_t = withUnsafeMutablePointer(to: &taskInfo) {         $0.withMemoryRebound(to: integer_t.self,capacity: 1) {             task_info(mach_task_self_,task_flavor_t(MACH_TASK_BASIC_INFO),$0,&count)         }     }       if kerr == KERN_SUCCESS {         return taskInfo.resident_size     }     return 0 } not working, apparently. When my system uses 15 GB it shows it's below 1 GB. Do anyone have other ways to get memory usage of the device (better macOS)

Hi there, While developing my first kernel extension for a learning purpose, I'm facing the issue above, "Bad code signature". The actual steps to reproduce are as follows: \ Initialize my Xcode project using the template "Generic Kernel Extension". Implement a fundamental extension that displays "Hello World!" using printf();. Build and sign it as "Sign to run locally". Put the "HelloWorld.kext" bundle into the /Library/Extensions/. Change the owner of the bundle file to "root:wheel". Load the extension using as follows. $ cd /Library/Extentions $ sudo kextload /Library/Extensions/HelloWorld.kext Password: Executing: /usr/bin/kmutil load -p /Library/Extensions/HelloWorld.kext Error Domain=KMErrorDomain Code=29 "Authenticating extension failed: Kext com.martymarron.HelloWorld v.1.0.0 in executable kext bundle com.martymarron.HelloWorld at /Library/Extensions/HelloWorld.kext: Authenticating extension failed: Bad code signature" UserInfo={NSLocalizedDescription=Authenticating extension failed: Kext com.martymarron.HelloWorld v1.0.0 in executable kext bundle com.martymarron.HelloWorld at /Library/Extensions/HelloWorld.kext: Authenticating extension failed: Bad code signature} I guessed that the bundle needs to be signed anyway. Hence I signed it for "development", but it resulted in the same. Some article says that my developer account should be enabled for "KEXT development" on https://developer.apple.com/resources/developer-id/, but this link does not work now. Referred article: https://developer.apple.com/forums/thread/30703 Then, I found the article below says "the kernel doesn't load a kext if an equivalent System Extention solution exists". https://developer.apple.com/documentation/kernel/implementing_drivers_system_extensions_and_kexts Does this mean the kernel extension development on my environment is no longer supported? Or is there still the way to try the kernel extension development on my environment? If no, I'll give up trying it and will try "system extension development" instead. Thanks for your kind help! My development environment: OS ver: Monterey(12.5) CPU Arch: Intel Core i7 Xcode ver: Version 13.4.1 (13F100)

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!