site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com All, I'd appreciate a little bit more information about some points in this thread, specifically what Terry said in points (3) and (4). I'd like to implement a technique that's very similar to Time Machine. Basically, a userland process would register with the kernel extension and provide a pid. The kernel extension would call the userland application whenever a vnode scope operation is performed by the pid. The userland app would then create a backup of the file that's being accessed. In this case I want to have blocking communication between the kernel and the userland application so that I can create the backup before the application can access the file. This is very similar to a hypothetical virus scanner so many of the techniques should apply. I've read TN2127 and the list archives about implementing a virus scanner and one question that's never been definitively answered is how the kernel can block and then call out to a user level application. In fact TN2127 says in the Listener Gotchas section that the only foolproof method is the implement the scanner completely in the kernel. Is this still the recommended approach? If it is will I be able to implement my version of Time Machine? The statement: For example, an anti-virus scanner would particularly want to scan files being opened by a thread running with elevated privileges. In this case the only correct solution is for the scanner to operate entirely within the kernel. The correct method involves my item (1): (1) Exempting your virus scan daemon from such checks when it makes requests, by having it register its process with your KEXT -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Aug 5, 2007, at 7:07 PM, Jim Clause wrote: Any such operation would need to be blocking, in fact, or you would be giving them the answer before you had it yourself (assuming a user space daemon is involved), which is impossible. is incorrect; there is no reasonable way to do low level file I/O from within a KEXT. This is an intentional design decision, and it's unlikely to ever change. Since a virus scanner will, by necessity, need to look at the contents of the files it is scanning, the statement can't be correct, for obvious reasons. The caveat here is that you may not rely on other system services, other than very simple system calls, if you want to avoid the possibility of deadlock. So, for example, a virus scanner would not want to link against Core Foundation, nor would it want to make name resolution requests for network host names, etc.. In other words, you limit yourself to functions in man(2) (system calls) and avoid those in man(3) (library routines). However, for the most part, the daemons in question that are contacted by library routines behind your back run as "root", so the chance of deadlock from that is more or less minimal, if you also follow the recommendation that you exempt not only your virus scanner, but also applications running as "root". My personal opinion in this case is that you should limit your APIs rather than doing this, as the threat to the system of a root process triggering virus code is much higher than that for a non-root process triggering the same code at a lower privilege level. What this really boils down to is that I think that your daemon should be in a state where it has all the information it needs in order to make the decision in hand, rather than needing to go elsewhere to obtain it; this also avoids the possibility of a deadlock, and is a much more elegant approach to the deadlock problem. This email sent to site_archiver@lists.apple.com