xnu

问题 I'm looking through the syscalls.master file here but it isn't at all documented. Does documentation for the syscalls exist? If not, why not? By documentation I mean an actual explanation of what each syscall does and the meanings of the arguments it takes. 回答1: Apple's position is that the system libraries are the API and stable ABI, syscalls are not. They discourage their direct use, as they can change from release to release of the OS. So, the best documentation you'll see is the man pages

问题 I noticed that upon an invalid 64bit MacOS syscall xor eax,eax syscall ;lldb stops here after the syscall When lldb stops the process while single stepping on: thread #1, stop reason = EXC_SYSCALL (code=5797, subcode=0x1) The rcx is equal to rsp . However when lldb is not attached or is not single stepping rcx is equal to expected return address after the syscall (i.e. is exactly of the same value as rip in user space). Is this some kind of a bug / side effect? I'm observing this on MacOS 10

问题 There doesn't appear to be synchronization between establishing/removing callbacks (e.g. kauth_unlisten_scope) and the callbacks themselves (in the xnu codebase, yes, I know, it's dated). This puts the burden of tracking/draining callbacks and synchronizing with calls on the extension itself. But this is problematic as well in that there is a window in noting that a thread has exited the callback AND actually returning out of the extension code. Is there any pattern that gives a correct

问题 In order to achieve better encapsulation and modularity I've decided to split my kernel driver into 2 (can be more) modules where each is responsible for different functionality. However, there are still some data+logic which I'd like to share between those modules (i.e. one module can manage the communication with user-space, while the other uses it as mediator) and I wonder if there's any easy way to do so. For example, I'd like to publish some API from one module to another, which is

问题 I'm trying to build POC that identify file copying activity from kauth based kernel extension that using fileop scope callback. However, it seems that copying file involves two separate authentication operations (open src file from and create new file). My goal is rather simple, detect the new target file creation after it was filled with data, disregarding the nature of the source file (so I'll be able to read it for further analysis) According to my observation, it may possible to achieve

问题 I'm debugging a driver that cause kernel dump on my mac. It shows long backtrace composed out of series of addresses: panic(cpu 6 caller 0xffffff8004dc9986): trying to interlock destroyed mutex (0xffffff8049deedb0) Backtrace (CPU 6), Frame : Return Address 0xffffff93b1c8bb50 : 0xffffff8004ce5307 0xffffff93b1c8bbd0 : 0xffffff8004dc9986 0xffffff93b1c8bbe0 : 0xffffff8004d099eb 0xffffff93b1c8bc20 : 0xffffff7f85604899 0xffffff93b1c8bc50 : 0xffffff800519776b 0xffffff93b1c8bc90 : 0xffffff80051f336c

问题 I'd like to have dtrace script that print new processes' cmdline and their matching parent name. i.e. : if I ran /Users/bla/myexec arg1 arg2 arg3 from bash I will get something like : parent is bash process is --> /Users/bla/myexec arg1 arg2 arg3 After searching here and here I came up with the following solution : #!/usr/sbin/dtrace -s proc:::exec { self->pexecname = execname; } proc:::exec-success / self->pexecname != 0 / { this->isx64=(curproc->p_flag & P_LP64)!=0; #define SELECT_64_86(x64

问题 I've created uninstaller for my driver, that remove its matching plist file from /Library/LaunchDaemons so that it won't be loaded again by launchd on the next boot cycle. However, it doesn't seems to take any effect on my driver that is still being loaded normally after booting the machine. After doing some research in this matter, I've found out that the kextcache is the reason for this behaviour, and in order clean/invalidate it, I need to touch the folder where the installation target

问题 I want to provide a user space function that obtains TCP connection stats by implementing a kernel extension. From examining the TCP source, I see the tcpcp struct holds such stats. How can I, given a socket handle from user space, obtain the associated tcpcb struct via a kernel extension and return the stats to user space? 回答1: Direct answer to the question: I believe you can't get at this information from a kext without using some private headers to get the memory layout of the structs

问题 Google yields no insight. I wasn't able to figure it out by searching around in the kernel source. I'm using the open source IOProxyVideoFamily to implement a virtual framebuffer. I just replaced a C-style cast to IODeviceMemory with OSDynamicCast, because I suspect that cast will fail. If so I will know how to fix it. But I can't find the KPI library that contains it. IODeviceMemory has been in the OS since 10.0, and is required for PCI card drivers. $ kextlibs -undef-symbols /System/Library