site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Several ways: Do we *really* need to send a feature request to [...] provide a truly authorized KPI for legitimate patches? Only if you want the KPI to actually get implemented. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Aug 16, 2007, at 9:29 AM, Ernesto Corvi wrote: On Aug 15, 2007, at 7:24 PM, Terry Lambert wrote: We hide system calls so someone unscrupulous does not overwrite their entry points with jump instructions to their own code, perhaps thinking that we do not change locking or other implementations details in software updates. If you need to trap and/or prevent this type of operation for legitimate reasons, use kauth instead. How is that going to prevent any unscrupulous people from hooking into the kernel? I'm baffled. (1) By providing KPI which will not destabilize the kernel when you use it (2) By being responsive to reasonable requests for new KPI that come through proper channels; going through proper chanlles gets you an advocate in DTS to push your request (3) By making it more work to go around the KPI than to use the KPI; it's not impossible to do this; it's just intentionally painful: that's why this discussion really has nothing to do with security (4) Through peer pressure/Professional ethics ["You should care about not breaking my app so I care about not breaking yours"] An unscrupulous person most likely doesn't care at all if his code runs with the next software update. And this is precisely what makes them unscrupulous, whether they are a garage developer or employed by a Fortune 500 company. BTW: a "scruple", according to Webster's dictionary, is "an ethical consideration or principle that inhibits action". Unlike user space instability, which will impact at most one or two applications (usually the ones that are unstable to start with), kernel space instability impacts everyone. When writing code that runs in the kernel address space (a KEXT), there is necessarily a higher standard to which a professional needs to hold themselves. This higher standard is not obvious unless the engineer has either worked in a kernel or programmed on a machine without memory protection before; that's one of the reasons I said that the original post was to the wrong mailing list -- it should have been posted to "kernel", not "dev", where people just take this idea for granted. Requests from developers carry much more weight with feature planners than do comments by insiders who "saw something on some mailing list". This is why people constantly suggest you file bug reports. Even if you happen to be chatting on a mailing list with the person who will eventually get that bug report, or be tasked with implementing the feature, that's not really going to carry any weight with feature planners, who give more weight to documented customer demand for something. This email sent to site_archiver@lists.apple.com