site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=W6wcOdbqr0d15oZSvxlvRYVwqMFvxvRvM9bng1z4TqcLG+2O8vwRf3C4DKXAnjEoOTTwRfzCUf8arx8hrnnDOYeabkGg5JhudCX8cRXvoUhKeKRgIjRfi+QbRy14StIV9xhisAM9p7Cp+LV8YtFfkM6Nd6TPM1iR4PmFU+B/tyc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=dGYgknjV7leo4dKFF8kL3k6hJ5a7zCjaJUjnkx6qKMFfA2uB4cnzgto/42N5Fkam0nLIk1FBsksVFepCpQIbQIU1FGdDSxcLhrnv4J7tXjH107AJKKI1RcTqcg/jyu+gxVPn4cyNEzc5MuA+lKQ5ex3Gqaw/Yb5oZ/4/KqQU1x4= Thanks for the info. lol, should i be impressed with your email address as well? _______________________________________________ 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 1:16 AM, Michael Smith wrote: It does not, beyond causing the failure of operations requesting directions that would violate the task's mapping protections. The sort of operation you're describing is not part of the operation model for any I/O Kit driver or family, so no, there are not. As a general rule, tasks don't expect operations to have that sort of permanent side-effect - there are interfaces that they may call if it's what they want. It is, of course, possible to remap client address ranges in the kernel with differing protections. This is documented in the literature and has been widely discussed here and on other Darwin lists. I/O Kit kexts are linked against the symbol sets on which they declare dependencies. This facilitates a number of useful and largely invisible features. ... which would of course prove the point that you mistakenly think Terry was making, beyond any contradiction. As has clearly been articulated in both this thread and many others preceding, this has nothing to do with security. It is a matter of providing sustainable interfaces to developers and techniques for managing situations where interfaces have to change in a graceful fashion. I think the preceding threads prove my point that there is a demand from the development community to provide kernel hooks even if the interface is volatile. If Apple doesn't provide one, then that makes me think they dont want to because it could destroy the user expierence with kernel panics. The downside to that is, if Apple doesn't provide a regulated but liberal interface into the kernel the developers will create their own. With my proposed plan at least gives the user fair warning, whereas the present solution requires me to hook it manually, leaving the possibility i would never inform the user of the hook and the resulting panics being perceived by the user to be Apple's fault. Terry did say that "We hide system calls so someone unscrupulous..." can't hook them. The act of hiding something from a unscrupulous person directly implies the act of hiding to be a security measure, see my first reply to him for a definition of unscrupulous. I'm sure if you were to check Terry's e-mail address you would in fact find that he is paid on a daily basis to come up with better ideas than yours, and perhaps it would be worth your while to sit back for a bit and think about what has actually been said in this thread, and the many on related subjects prior, before leaping back into the fray. This email sent to site_archiver@lists.apple.com