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.
Several ways:
(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.
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.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
