site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thanks, - Dean _______________________________________________ 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 Dec 14, 2008, at 7:47 PM, John D. wrote: On Sun, Dec 14, 2008 at 8:33 PM, Terry Lambert <tlambert@apple.com> wrote: You file a bug report with DTS. OK, thanks. This is good advice; if you need functionality that is not currently provided via KPI, then asking for new KPI is the best way to go. There is no guarantee that we will provide every requested KPI, but we can't provide what we don't know is needed. Apple cannot support every symbol in the kernel as an expansion point, otherwise we would have to freeze the kernel as it is now and never make any changes. Of course you don't need every symbol, just a few... But if another hundred developers felt free to grab the one or two extra symbols they need, we are left with an unsupportable mess, and our customers (and our reputation) suffer when these kexts start to panic after a software update. The KPIs are our supported kernel interfaces; you are free to use them for kernel extensions with a reasonable assurance of compatibility with future versions of the OS. Circumventing our linking mechanism to find private symbols you are interested in is not acceptable practice for any product that will find its way into a customer's hands. While we don't claim to be perfect, we do work very hard to avoid breaking the KPIs between releases. Any interface that is not exported as a KPI is considered private to Apple and safe for us to change at any time, even a dot release. Attempting to make use of non- KPI symbols will almost certainly cause a bad user experience in the future. This is something we intentionally do not permit. A lot of antivirus vendors were doing this and it broke our locking model. So we provided KPI to let them intercept operations (that is called "kauth" and you can find documentation on <http:// developer.apple.com>). If we change locking in the future, we won't break them again. Problem with kauth is that AFAIK it only let's you return 'deny' or 'pass' results. If, say, you want to return a ENOENT or special errno to the syscall, it's not possible through kauth. Most of the API used in unix_syscall isn't available in any KPI. Yes. On purpose. I personally made the syscall table a private symbol. The problem is that it's a hassle for legitimate developers. People trying to subvert the kernel might simply go and patch the IDT or do something far more complex. Plus a memory search will yield sysent's location easily. It isn't a hassle for legitimate developers because they loose that status as soon as they step outside our KPI space. Thus far, we have not introduced strong protections to prevent developers getting at things we don't export, but that may change if we see customer problems resulting from such practice. That leaves us with either patching its code on runtime (a hack, which apparently isn't possible because that region isn't writable; I'm not sure why kernel TEXT wouldn't be writable except for security reasons I guess) or forgetting about implementing anything around it. We're mildly clever that way. I was hoping we could vm_map_mprotect or alike the kernel text temporarily. Do you know if this is feasible without resorting to a non portable hack? If you are considering this, you are already well within "non portable hack" territory. Kernel text is made read-only because there is no legitimate need to modify it. You may strongly want to modify kernel text, but this is not supported and any attempts to do so are ill advised. I should add that everything I've said above only applies to Mac OS X (the product). The Darwin Kernel is open and a completely reasonable place to experiment when you need access to more kernel bits than KPIs allow. This is why the first advice you received was to build your own kernel. This email sent to site_archiver@lists.apple.com