How can I achieve a safe space on the same computer,Realize a multi-purpose machine. In the safe space, I can use the A application, but not the B application. I can use the C network, but not the D network. I can read and write files inside the safe space. Outside the safe space, I can use all applications, all networks I can use , but I can't read and write files in secure space ps：Content FIlter and endpoint control the entire computer. Can't achieve dual use in one machine

My understanding of sigaction is that my signal handler function should get a siginfo_t argument with the pid and uid of the process sending the signal. #include <stdatomic.h> #include <signal.h> #include <stdio.h> #include <unistd.h> #include <stdlib.h> static atomic_int gTermParentPid = -1; static void SigTermHandler(int signalValue, siginfo_t *info, void *uap) { gTermParentPid = info->si_pid; } int main(int argc, const char * argv[]) { struct sigaction handlerAction; handlerAction.sa_sigaction = SigTermHandler; handlerAction.sa_flags = SA_SIGINFO; sigemptyset(&handlerAction.sa_mask); if (sigaction(SIGTERM, &handlerAction, NULL) != 0) { perror(NULL); abort(); } printf("pid: %d\n", getpid()); while (gTermParentPid == -1) { sleep(1); } printf("ParentPid: %d\n", gTermParentPid); } so when I run the above program and then send it a kill from another shell I would expect it to log the pid of the shell I sent the kill from. In all cases though I am getting a pid and uid of 0. Is this expected? This seems to work fine on linux. I tested this with a variety of other signals (SIGALRM, SIGINT) with the same results. Not sure if Exception Handling was the right tag, but it was the closest I could find. Filed as FB11850436 as well.

I have this piece of code in a Mac OS app which at runtime iterates through memory regions of a process. The purpose is finding where dyld is loaded and based on that i'm obtaining other info.  To achieve this goal i am calling vm_region_recurse_64 in a loop until it returns a non-zero result. I am also increasing depth each time a region is_submap, so i get to iterate child memory regions. With each region I store its start address and size allowing me to later inspect them, looking for a mach_header_64.  With this introduction let me describe the issue i'm seeing. On Mac OS Monterey 12.5.1 (and older releases) starting at offset 0 inside a memory region, i will find the MH_MAGIC_64 which is 0xfeedfacf, and with a few bytes offset there will be the filetype of MH_DYLINKER. At that moment i know the current region is where dyld was loaded.  On Mac OS Ventura 13.0.1, the dyld cannot be found at the start of any memory region. Instead it can be found at an offset of 8kb inside one of the memory regions, which is unexpected.  I'm trying to understand what changed with Ventura and if that change can be flag-controlled in any way. Are there any set expectations about the offset where i should look? Or maybe verifying all addresses with increments of say, 1k until i find it (therefore it being memory aligned)? That's because sequentially iterating every byte of memory in every region is not a viable option. And if i should drop this method, Is there a better way to get to that memory? Thanks,

For example, I see that Ventura RC1 runs kernel release xnu-8792.41.6~5 Darwin MacBook-Air-3.local 22.1.0 Darwin Kernel Version 22.1.0: Tue Sep 27 22:07:43 PDT 2022; root:xnu-8792.41.6~5/RELEASE_ARM64_T8103 arm64 Where can I find these sources? tks

So we have produced kexts that run well, on Intel and Arm64, on (for example) an MBP/M1 (all macOS currently available), and MacStudio (Monterey). But on Monterey + Ventura it enters a boot panic loop. One example is: "build" : "macOS 13.1 (22C5033e)", "product" : "Mac13,2", "socId" : "0x00006002", "kernel" : "Darwin Kernel Version 22.2.0: Sun Oct 16 18:09:52 PDT 2022; root:xnu-8792.60.32.0.1~11\/RELEASE_ARM64_T6000", "incident" : "8D3814E3-DCBB-42A6-AACF-C37F66D6BBC8", "crashReporterKey" : "FF922DC9-99E1-68B9-75FB-9427F2BBF431", "date" : "2022-10-28 00:12:53.22 +0100", "panicString" : "panic(cpu 6 caller 0xfffffe001e4b11e8): \"apciec[pcic2-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x02220060 linkcdmsts=0x00000000 (ltssm 0x11=L0)\\n\" @AppleT8103PCIeCPort.cpp:1301\n Debugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 22C5033e\nKernel version: Darwin Kernel Version 22.2.0: Sun Oct 16 18:09:52 PDT 2022; root:xnu-8792.60.32.0.1~11\/RELEASE_ARM64_T6000\nFileset Kernelcache UUID: D767CC1C43ABBCC48AD47B6010804F47\nKernel UUID: 99C80004-214F-342C-ADF2-402BC1EAC155\nBoot session UUID: 8D3814E3-DCBB-42A6-AACF-C37F66D6BBC8\niBoot version: iBoot-8419.60.31\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x00000000149f4000\nKernelCache base: 0xfffffe001b9f8000\nKernel slide: 0x0000000015c54000\nKernel text base: 0xfffffe001cc58000\nKernel text exec slide: 0x0000000015d40000\nKernel text exec base: 0xfffffe001cd44000\nmach_absolute_time: 0x1506187a\nEpoch Time: sec usec\n Boot : 0x635b102d 0x0009de48\n Sleep : 0x00000000 0x00000000\n Wake : 0x00000000 0x00000000\n Calendar: 0x635b1035 0x000bfb29\n\nZone info:\n Zone map: 0xfffffe10219f0000 - 0xfffffe30219f0000\n . VM : 0xfffffe10219f0000 - 0xfffffe14ee6bc000\n . RO : 0xfffffe14ee6bc000 - 0xfffffe1688054000\n . GEN0 : 0xfffffe1688054000 - 0xfffffe1b54d20000\n . GEN1 : 0xfffffe1b54d20000 - 0xfffffe20219ec000\n . GEN2 : 0xfffffe20219ec000 - 0xfffffe24ee6b8000\n . GEN3 : 0xfffffe24ee6b8000 - 0xfffffe29bb384000\n . DATA : 0xfffffe29bb384000 - 0xfffffe30219f0000\n Metadata: 0xfffffe3021a00000 - 0xfffffe3029a00000\n Bitmaps : 0xfffffe3029a00000 - 0xfffffe3049a00000\n\nTPIDRx_ELy = {1: 0xfffffe29bae26818 0: 0x0000000000000006 0ro: 0x0000000000000000 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 0: PC=0x00000001af0305ec, LR=0x00000001af0304e8, FP=0x000000016dda6200\nCORE 1: PC=0x00000001aeee1c94, LR=0x00000001bb020624, FP=0x000000016e206140\nCORE 2: PC=0xfffffe001d4a15e0, LR=0xfffffe001d4a14cc, FP=0xfffffe8ff2263d30\nCORE 3: PC=0xfffffe001cd9c9f8, LR=0xfffffe001d6eac6c, FP=0xfffffe80212ab920\nCORE 4: PC=0xfffffe001d416704, LR=0xfffffe001d4a265c, FP=0xfffffe802138fd50\nCORE 5: PC=0xfffffe001cd9c974, LR=0xfffffe001f14aca0, FP=0xfffffe8020a4ba50\nCORE 6 is the one that panicked. Check the full backtrace for details.\nCORE 7: PC=0xfffffe001cdbbad0, LR=0xfffffe001cdbbb88, FP=0xfffffe8ff1f6fd90\nCORE 8: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020edff00\nCORE 9: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8ff2197f00\nCORE 10: PC=0xfffffe001cfd1054, LR=0xfffffe001f9d7d14, FP=0xfffffe8ff1f87610\nCORE 11: PC=0x00000001b2064b88, LR=0x00000001b2064af0, FP=0x000000016f3e5860\nCORE 12: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8021543f00\nCORE 13: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020963f00\nCORE 14: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020adff00\nCORE 15: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020a03f00\nCORE 16: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8ff1f4bf00\nCORE 17: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe802146bf00\nCORE 18: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8ff21c7f00\nCORE 19: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe88090fff00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe168805d678: 0 pages, 1020 threads: pid 0: kernel_task\nPanicked thread: 0xfffffe29bae26818, backtrace: 0xfffffe80213176a0, tid: 285\n\t\t lr: 0xfffffe001cda2adc fp: 0xfffffe8021317710\n\t\t lr: 0xfffffe001cda2884 fp: 0xfffffe8021317790\n\t\t lr: 0xfffffe001cf06a18 fp: 0xfffffe80213177b0\n\t\t lr: 0xfffffe001cef7f88 fp: 0xfffffe8021317820\n\t\t lr: 0xfffffe001cef588c fp: 0xfffffe80213178e0\n\t\t lr: 0xfffffe001cd4b7f8 fp: 0xfffffe80213178f0\n\t\t lr: 0xfffffe001cda220c fp: 0xfffffe8021317ca0\n\t\t lr: 0xfffffe001d5e6b74 fp: 0xfffffe8021317cc0\n\t\t lr: 0xfffffe001e4b11e8 fp: 0xfffffe8021317d80\n\t\t lr: 0xfffffe001e4be774 fp: 0xfffffe8021317e50\n\t\t lr: 0xfffffe001d4ea934 fp: 0xfffffe8021317ea0\n\t\t lr: 0xfffffe001d4e6b54 fp: 0xfffffe8021317ee0\n\t\t lr: 0xfffffe001d4e779c fp: 0xfffffe8021317f20\n\t\t lr: 0xfffffe001cd54e98 fp: 0x0000000000000000\n Kernel Extensions in backtrace:\n com.apple.driver.AppleT6000PCIeC(1.0)[D6E00E5A-7BC8-33A5-9CDC-C4CF13DB1C01]@0xfffffe001e4a2250->0xfffffe001e4c7fa3\n dependency: com.apple.driver.AppleARMPlatform(1.0.2)[F8A12C7A-9C6E-3DCC-A2C3-56A2050A7E73]@0xfffffe001d78def0->0xfffffe001d7dc45f\n dependency: com.apple.driver.AppleEmbeddedPCIE(1)[2BA5358A-87CA-33DF-A148-FFE0C2733367]@0xfffffe001ddc8400->0xfffffe001dde2817\n dependency: com.apple.driver.ApplePIODMA(1)[7CB8682A-FA16-3841-9E30-B6032E5C6925]@0xfffffe001e1d7e60->0xfffffe001e1dc5eb\n dependency: com.apple.driver.IODARTFamily(1)[5C3EEB18-7785-328B-B994-3B0DA5B7D2FE]@0xfffffe001edfd870->0xfffffe001ee1135f\n dependency: com.apple.iokit.IOPCIFamily(2.9)[D6265950-5027-3125-A532-DC325E6A0639]@0xfffffe001f176220->0xfffffe001f1a12a3\n dependency: com.apple.iokit.IOReportFamily(47)[ED601736-6073-3B7D-A228-0FEC344992FA]@0xfffffe001f1a4ee0->0xfffffe001f1a7ecb\n dependency: com.apple.iokit.IOThunderboltFamily(9.3.3)[4F558D51-13A7-3E87-AAD6-23E0A7C0A146]@0xfffffe001f2a02c0->0xfffffe001f3dbd4f\n\nlast started kext at 341403491: com.apple.UVCService\t1 (addr 0xfffffe001c13a690, size 1772)\nloaded Presumably our kext is guilty of something, but it isn't (obviously) involved yet. Machine generally boots without our kext, but not always. Same kext works on Monterey, as well as Ventura on M1. Any particular areas to look at for this kind of panic? Are there hints in the stack? (can we resolve panic stack yet?)

hello friends, I am using macbook air 2015 early. My System has MacOS Monterey 12.6.1. I am using Xcode version 14.1. I've had system crashes twice. What is the most stable osx and xcode you would recommend for my macbook air 2015? Thank you. panic(cpu 2 caller 0xffffff8013d7a99f): userspace watchdog timeout: no successful checkins from WindowServer in 120 seconds service: logd, total successful checkins since wake (9840 seconds ago): 985, last successful checkin: 0 seconds ago service: WindowServer, total successful checkins since wake (9840 seconds ago): 973, last successful checkin: 120 seconds ago service: opendirectoryd, total successful checkins since wake (9840 seconds ago): 985, last successful checkin: 0 seconds ago Panicked task 0xffffff8bb881da20: 3 threads: pid 99: watchdogd Backtrace (CPU 2), panicked thread: 0xffffff8bb904e540, Frame : Return Address 0xfffffff2ad42b690 : 0xffffff801087de9d 0xfffffff2ad42b6e0 : 0xffffff80109e0556 0xfffffff2ad42b720 : 0xffffff80109cf8c3 0xfffffff2ad42b770 : 0xffffff801081da70 0xfffffff2ad42b790 : 0xffffff801087e26d 0xfffffff2ad42b8b0 : 0xffffff801087da26 0xfffffff2ad42b910 : 0xffffff80111146a3 0xfffffff2ad42ba00 : 0xffffff8013d7a99f 0xfffffff2ad42ba10 : 0xffffff8013d7a5f2 0xfffffff2ad42ba30 : 0xffffff8013d79971 0xfffffff2ad42bb60 : 0xffffff8011082e1c 0xfffffff2ad42bcc0 : 0xffffff8010986256 0xfffffff2ad42bdd0 : 0xffffff80108589cb 0xfffffff2ad42be60 : 0xffffff801086f2d9 0xfffffff2ad42bef0 : 0xffffff80109b252a 0xfffffff2ad42bfa0 : 0xffffff801081e256 Kernel Extensions in backtrace: com.apple.driver.watchdog(1.0)[F91132C0-8345-3E3E-B826-851CC2EC465A]@0xffffff8013d78000->0xffffff8013d7afff Process name corresponding to current thread (0xffffff8bb904e540): watchdogd Mac OS version: 21G217 Kernel version: Darwin Kernel Version 21.6.0: Thu Sep 29 20:12:57 PDT 2022; root:xnu-8020.240.7~1/RELEASE_X86_64 Kernel UUID: 54B44BAE-1625-30CC-80B0-29E4966EFFDC KernelCache slide: 0x0000000010600000 KernelCache base: 0xffffff8010800000 Kernel slide: 0x0000000010610000 Kernel text base: 0xffffff8010810000 __HIB text base: 0xffffff8010700000 System model name: MacBookAir7,2 (Mac-937CB26E2E02BB01) System shutdown begun: NO Panic diags file available: YES (0x0) Hibernation exit count: 0

I am trying to compile the IOPCIFamily kext, but it isn't working with me. I'm normally pretty good with troubleshooting, but I'm at a complete loss. I don't even know where to begin 😆 I saw someone say on a thread from 4 years ago that you need to compile XNU to compile IOPCIFamily. I successfully compiled XNU (after much trial and error), but now I'm not sure what to do with it. Could anyone point me in the right direction? Thanks!

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

I am new to Mac Os kext development. I want to develop a device driver on macOS Mojave (10.14.2) for my device. I created a demo to check the running process of the driver, but after actually running it, I didn't find any log about the driver. The following is the source code. Compile with xcode. IOKitTest.cpp /* add your code here */ #include "IOKitTest.hpp" #include <IOKit/IOService.h> #include <IOKit/IOLib.h> // 类似cocoa中 super关键字 #define super IOService // 和头文件中的宏定义类似, 自动生成一些特定的代码 OSDefineMetaClassAndStructors(com_apple_driver_IOKitTest, IOService); bool com_apple_driver_IOKitTest::init(OSDictionary *dict) {   bool result = super::init(dict);       IOLog("IOKitTest : did init !! \n"); // IOlog() 生成log日志, 存在在system.log里       log = os_log_create("com.apple.driver", "XmX");   os_log(log, "xmx Tests!!");       /** 遍历OSDictionary */   OSCollectionIterator *iter = OSCollectionIterator::withCollection(dict);   if (iter)   {     OSObject *object = NULL;     while ((object = iter->getNextObject()))     {       OSSymbol *key = OSDynamicCast(OSSymbol, object);       IOLog("iRedTest : key:%s ",key->getCStringNoCopy());       OSString *value = OSDynamicCast(OSString, dict->getObject(key));       if (value != NULL)       {         IOLog("iRedTest : value:%s\n",value->getCStringNoCopy());       }     }   }       return result; } void com_apple_driver_IOKitTest::free(void) {   IOLog("IOKitTest : free \n");   os_log(log, "xmx Tests!!");   super::free(); } IOService *com_apple_driver_IOKitTest::probe(IOService *provider, SInt32 *score) {   IOService *probe = super::probe(provider, score);   return probe; } bool com_apple_driver_IOKitTest::start(IOService *provider) {   bool result = super::start(provider);   IOLog("IOKitTest : start \n");   os_log(log, "xmx Tests!!");   return result; } void com_apple_driver_IOKitTest::stop(IOService *provider) {   IOLog("IOKitTest : stop \n");   os_log(log, "xmx Tests!!");   super::stop(provider); } IOKitTest.hpp /* add your code here */ #include <IOKit/IOService.h> #include <os/log.h> #ifndef IOKitTest_hpp #define IOKitTest_hpp class com_apple_driver_IOKitTest : public IOService {       //一个宏定义，会自动生成该类的构造方法、析构方法和运行时   OSDeclareDefaultStructors(com_apple_driver_IOKitTest);     public:   // 该方法与cocoa中init方法和C++中构造函数类似   virtual bool init(OSDictionary *dict = 0) APPLE_KEXT_OVERRIDE;   // 该方法与cocoa中dealloc方法和c++中析构函数类似   virtual void free(void) APPLE_KEXT_OVERRIDE;   // 进行驱动匹配时调用   virtual IOService *probe(IOService *provider, SInt32 *score) APPLE_KEXT_OVERRIDE;   // 进行加载时调用   virtual bool start(IOService *provider) APPLE_KEXT_OVERRIDE;   // 进行卸载时调用   virtual void stop(IOService *provider) APPLE_KEXT_OVERRIDE;       os_log_t log; }; #endif /* IOKitTest_hpp */ info.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>IOKitPersonalities</key> <dict> <key>IOKitTest</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.IOKitTest</string> <key>IOClass</key> <string>com_apple_driver_IOKitTest</string> <key>IOMatchCategory</key> <string>com_apple_driver_IOKitTest</string> <key>IOProbeScore</key> <integer>10000</integer> <key>IOProviderClass</key> <string>IOResource</string> <key>IOResourceMatch</key> <string>IOKit</string> </dict> </dict> <key>NSHumanReadableCopyright</key> <string>Copyright © 2022 JingCe. All rights reserved.</string> <key>OSBundleLibraries</key> <dict> <key>com.apple.kpi.iokit</key> <string>18.2.0</string> <key>com.apple.kpi.libkern</key> <string>18.2.0</string> </dict> </dict> </plist> After the driver is loaded kextstat shows Does the above indicate that the driver is loaded successfully? where to view the kernel log？ Where can I learn kext demo？

Is there any proper documentation for how the thread properties qualityOfService and priority are related? Is one the broad sword and the other one the fine one? If so, which is which? Background: I have an iOS app that communicates with hardware. For some operations, the hardware has tight timelines, hence I would need to prioritize the communication thread over the UI thread (which is rare, but in this case necessary in order to prevent damaging the hardware). Can anyone shed light on that or can I read up on the exact scheduler's behavior?

I'm looking at getting Valgrind to run on macOS 10.15 Catalina.So far I have the build working OK (based on a fork for 10.14 plus a few tweaks specific to 10.15).However when I run Valgrind [and I'm running the minimal --tool=none with an app that is just "int main(void) {}"] then I'm getting an error related to pthread_init. From what I see from the executed machine code, there is a test for _os_xbs_chrooted (a global variable in the kernel by the looks of it) which then leads to a call to __pthread_init.cold.2. This function contains a ud2 opcode which triggers a SIGILL in the Valgrind VM.Dearching google for _os_xbs_chrooted doesn't come up with anything much. There's this https://github.com/apple/darwin-libpthread/blob/master/src/pthread.c for the pthread check, and one other reference for the initialization.I realize this looks like it could be security related and information is not made public.Any suggestions as to how I can proceed? I have little experience in kernel programming.

Hello,I am having an hard time figuring out how memory mapped files works under iOS. Suppose that I want to read a big file, let's say 4GB. If I use memory mapped files in READ mode I should be able to get a valid pointer to a file and benefit from the page fault mechanism of virtual memory but apparently iOS can map only up to 2.5GB of data. I run the following test on an iPad Pro A1673 that has 2GB of ram and got as result:2018-04-06 17:20:12.660888+0200 TestMemory[414:316466] Data address: 0x1022240002018-04-06 17:20:12.662355+0200 TestMemory[414:316466] Data address: 0x1122240002018-04-06 17:20:12.663801+0200 TestMemory[414:316466] Data address: 0x12b9000002018-04-06 17:20:12.665235+0200 TestMemory[414:316466] Data address: 0x13b9000002018-04-06 17:20:12.666756+0200 TestMemory[414:316466] Data address: 0x14b9000002018-04-06 17:20:12.668202+0200 TestMemory[414:316466] Data address: 0x15b9000002018-04-06 17:20:12.669597+0200 TestMemory[414:316466] Data address: 0x16ff240002018-04-06 17:20:12.739549+0200 TestMemory[414:316466] Data address: 0x1e00000002018-04-06 17:20:12.747604+0200 TestMemory[414:316466] Data address: 0x1f00000002018-04-06 17:20:12.749130+0200 TestMemory[414:316466] Data address: 0x2000000002018-04-06 17:20:12.764753+0200 TestMemory[414:316466] NSData failed: Error Domain=NSCocoaErrorDomain Code=256 "The file “02808580-5D42-43BC-B5AA-628E3682A546” couldn’t be opened." UserInfo={NSFilePath=/var/mobile/Containers/Data/Application/5207275C-5525-47CA-AC4B-2AA07E05C1E9/Documents/02808580-5D42-43BC-B5AA-628E3682A546, NSUnderlyingError=0x1c0455270 {Error Domain=NSPOSIXErrorDomain Code=12 "Cannot allocate memory"}}2018-04-06 17:20:12.764801+0200 TestMemory[414:316466] Mapped 2684354560- (NSString*)createFileOfSize:(unsigned long long)size { NSString* uuid = [[NSUUID UUID] UUIDString]; NSString* documentFolderPath = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject].path; NSString* filePath = [documentFolderPath stringByAppendingPathComponent:uuid]; NSFileHandle *fileHandle = [NSFileHandle fileHandleForWritingAtPath:filePath]; if (fileHandle == nil) { [[NSFileManager defaultManager] createFileAtPath:filePath contents:nil attributes:nil]; fileHandle = [NSFileHandle fileHandleForWritingAtPath:filePath]; } [fileHandle truncateFileAtOffset:size]; [fileHandle closeFile]; return filePath; } - (void)test { const unsigned long long MB = 1 &lt;&lt; 20; const unsigned long long GB = 1 &lt;&lt; 30; unsigned long long space = 4 * GB; unsigned long long size = 64 * MB; unsigned long long fileCount = space / size; NSMutableArray* mapped = [NSMutableArray array]; int i = 0; for (i = 0; i &lt; fileCount; i++) { NSString* filePath = [self createFileOfSize:size]; NSError* error = nil; NSData* data = [NSData dataWithContentsOfFile:filePath options:NSDataReadingMappedAlways error:&amp;error]; if (error) { NSLog(@"NSData failed: %@", error); break; } else { const void* bytes = [data bytes]; NSLog(@"Data address: %p", bytes); [mapped addObject:data]; } } NSLog(@"Mapped %llu", i * size); }Any idea of why we have this limitation?Thanks!Libe

The following Python program hangs forever on MacOS, but does not hang on Linux: import os, termios, time device_fd, tty_fd = os.openpty() def loop(): while True: data = os.read(device_fd, 1) print(data) # <--- never gets here time.sleep(.1) from threading import Thread thread = Thread(target=loop, daemon=True) thread.start() os.write(tty_fd, b'123') termios.tcdrain(tty_fd) # <--- gets stuck here time.sleep(3) # allow thread to read all data When I sample the process using Activity Monitor I always get the following at the bottom of the call graph for the main thread: + 2553 termios_tcdrain (in termios.cpython-39-darwin.so) + 56 [0x1048dedcc] + 2553 tcdrain (in libsystem_c.dylib) + 48 [0x19f27c454] + 2553 ioctl (in libsystem_kernel.dylib) + 36 [0x19f30b0c0] + 2553 __ioctl (in libsystem_kernel.dylib) + 8 [0x19f30b0d4] Could someone help me understand why the program gets stuck on MacOS? I'm struggling to debug the problem beyond this point. I've attached the full sample. Other details: Tested on MacOS 12.5.1 (ARM CPU). Also tested on MacOS with an Intel CPU. Sample of python3.9.txt

I'm trying to gain some understanding of how mp_rendezvous works on x86, and I have a few questions: There are two variants, mp_rendezvous_no_intrs and mp_rendezvous. The first states that it disables interrupts during the execution of the requested function. However both boil down to mp_cpus_call1, which seems to disable interrupts for reasons not related to whether the "no_intrs" variant of mp_rendezvous was called (from osfmk/i386/mp.c), if the function is being called on cpus other than the master cpu: topo_lock = (cpus != cpu_to_cpumask(master_cpu)); if (topo_lock) { ml_set_interrupts_enabled(FALSE); (void) mp_safe_spin_lock(&x86_topo_lock); } Additionally interrupts seem to be disabled for the execution on the current CPU, as well: /* Call locally if mode not SYNC */ if (mode != SYNC && call_self) { KERNEL_DEBUG_CONSTANT( TRACE_MP_CPUS_CALL_LOCAL, VM_KERNEL_UNSLIDE(action_func), VM_KERNEL_UNSLIDE_OR_PERM(arg0), VM_KERNEL_UNSLIDE_OR_PERM(arg1), 0, 0); if (action_func != NULL) { ml_set_interrupts_enabled(FALSE); action_func(arg0, arg1); ml_set_interrupts_enabled(intrs_enabled); } } Finally, I noticed that if I have a function that is being called via mp_rendezvous, and trace it using DTrace, only the execution on the CPU that mp_rendezvous is called on hits the Dtrace probe. Is that because the other CPU's are executing the function on an interrupt thread when handling the IPI? Thank you, Neal

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() -&gt; UInt64 {     var taskInfo = mach_task_basic_info()     var count = UInt32(MemoryLayout&lt;mach_task_basic_info&gt;.size)     let kerr: kern_return_t = withUnsafeMutablePointer(to: &amp;taskInfo) {         $0.withMemoryRebound(to: integer_t.self,capacity: 1) {             task_info(mach_task_self_,task_flavor_t(MACH_TASK_BASIC_INFO),$0,&amp;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)