December 2008 - Darwin-kernel

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by John D. 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=THfH0Tz2ECjCIY9wGU0mSilhnLRijQXvRgfvr02TbMg=; b=RG9p4DD39E7dmf5wyU24aCRqIE35atfeOQqaeAgBNMiB19Lffy26WYUFgdugjwlL6W iN8TQgfnt9FMYoDEXP/ZGYQtmG2r/gqfMnZjphHrrA7/qC8DO7LehVkQ+p56ap1jB3CE yS+80r9B9AJsIdd77BGhIhoc2NWPEq+9JC7h4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZmD13/GSOidA7rb8T4kVP7NcxpFSkoKevcYMA75WvlQzJt3gjIYvNy1y20YpKmv7AM pSdRV+zHuVU66HsNVbjgzdGcJF+gOqkTP+LgW16E6593o6n5SmhG6mq8wNpQih9a9i1j SKI2UGufH9aB0oU2gZy3xNlYDqV1lpkGchXMM= On Mon, Dec 15, 2008 at 8:56 AM, Terry Lambert <tlambert(a)apple.com> wrote: > On Dec 14, 2008, at 10:16 PM, "John D." <johndenkar(a)gmail.com> wrote: >> >> On Mon, Dec 15, 2008 at 6:50 AM, Terry Lambert <tlambert(a)apple.com> wrote: >>> >>> On Dec 14, 2008, at 9:02 PM, "John D." <johndenkar(a)gmail.com> wrote: >>>> >>>> Excuse me, but monkey business is taking FreeBSD and Mach, creating a >>>> hybrid kernel, and crippling the API in a manner that doesn't let >>>> third-party developers exercise the best of both systems. Is that >>>> common sense? >>> >>> John, step down. >>> >>> I am the senior engineer on the Kernel team for BSD, Mike is more senior >>> than me, and Dean Manages the IOKit team. >>> >>> "No" means "No". >> >> I'm not questioning your knowledge here nor that of anyone else. I've >> got no time for it and no interest. Really. I came here asking why the >> BSD interfaces have been crippled to a certain extent, and that's it. >> If you don't want to provide a consistent answer it's fine, just don't >> enter a red herring argument about what makes your actual statements >> more reasonable than mine, when you are not providing technical facts >> supporting them. I could care less about your alleged pedigree. If >> one's professional position and its required knowledge matches his >> current skillset and reasoning is, again, moot. >> >> We might as well move on the question I sent about mbuf structures and >> NKE ipfilters. Those interfaces are examples of good work you've done >> there, so congratulations for that one. On other hand. I still think >> kauth is severely limited (crippled) as it is implemented right now. >> Check the current NetBSD code which is what you ported to XNU >> originally and adapt the new changes to XNU (from -CURRENT). > > We originated kauth. It is not a port from NetBSD. Thanks for playing, > though. If you originated it, then, why do you let NetBSD improve it beyond its current status in XNU itself? It's not like the BSD licensing stops you from taking their improvements. You've already used the whole FreeBSD kernel code base, porting some cleanroom implementation of your own kauth subsystem and improving it, can't hurt. Right? I guess you don't read NetBSD development lists regularly: http://archives.neohapsis.com/archives/netbsd/2007-q2/0023.html It's almost 2009 here. That thread is old enough to have gone unnoticed. Honestly, why don't you start bringing up some technical statements here? You keep resorting to either avoiding answering altogether, or replying with meaningless comments about why people should blindly take your statements and superior all-seeing knowledge for granted. Do you think I truly care on who originated kauth or who decided to cripple ABI in XNU kernel updates shipped customers after every major release or minor revision? I care about why kauth is severely limited, feature lacking and almost useless in XNU. I care about why most process, BSD thread or locking API has been crippled in XNU. If you plan on breaking ABI on every minor update, you might as well stop releasing source. Since you bring up the argument of 'customer support'... well, you suggest independent vendors shall ship custom builds of the XNU kernel to their customers and replace the official one shipping with OS X altogether? What kind of responsible development or life cycle is one which causes major ABI changes across third-level updates or minor releases? Even Linux 2.6 development people have got that right to a certain extent after a long time of finding themselves with severely broken drivers in the development tree. You want to break or cripple BSD kernel standard API? OK. You want to provide limited, restrictive interfaces branding them as KPI (when you are merely doing arbitrary changes to exported symbols and removing the availability of most of them)? That's fine too. You want to avoid answering questions from developers about why you've taken this decision single handed? That's fine! But then stop marketing XNU or Mac OS X as an open source or 'openly available and developer friendly' platform. If your developers can't write drivers because you've intentionally crippled your ABI/API, your platform does not qualify as open or developer friendly. In the end only Apple is able to provide closed source or binary-only drivers, not to mention the detrimental effect on potential third-party development of features that your user base might consider far more useful and necessary than what you might think in first place. So yeah, let's all drink the kool-aid and spice it up with some LSD and candy. No wonder some run out of arguments when they start repeating themselves over and over like a broken record. -- John Denkar _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by Terry Lambert 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com John, step down. I'm not questioning your knowledge here nor that of anyone else. I've got no time for it and no interest. Really. I came here asking why the BSD interfaces have been crippled to a certain extent, and that's it. If you don't want to provide a consistent answer it's fine, just don't enter a red herring argument about what makes your actual statements more reasonable than mine, when you are not providing technical facts supporting them. I could care less about your alleged pedigree. If one's professional position and its required knowledge matches his current skillset and reasoning is, again, moot. We might as well move on the question I sent about mbuf structures and NKE ipfilters. Those interfaces are examples of good work you've done there, so congratulations for that one. On other hand. I still think kauth is severely limited (crippled) as it is implemented right now. Check the current NetBSD code which is what you ported to XNU originally and adapt the new changes to XNU (from -CURRENT). -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 14, 2008, at 10:16 PM, "John D." <johndenkar(a)gmail.com> wrote: On Mon, Dec 15, 2008 at 6:50 AM, Terry Lambert <tlambert(a)apple.com> wrote: On Dec 14, 2008, at 9:02 PM, "John D." <johndenkar(a)gmail.com> wrote: Excuse me, but monkey business is taking FreeBSD and Mach, creating a hybrid kernel, and crippling the API in a manner that doesn't let third-party developers exercise the best of both systems. Is that common sense? I am the senior engineer on the Kernel team for BSD, Mike is more senior than me, and Dean Manages the IOKit team. "No" means "No". We originated kauth. It is not a port from NetBSD. Thanks for playing, though. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by jesuitx 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:to:content-type :mime-version:subject:date:x-mailer:from; bh=myf9/5MnaNa2uMMUovwN+b0N8DT0kw41f7pMlYbOCR4=; b=ne7IYbu+dP44eyMTnCar+G/QGiy/Nti92z1ThcwegI2e2Px/KMmgcwNsFDgUsOXwc1 2lzTq5E3uijj15jmrwY+7YlXoQ/qedqMEAqpl/ViKKl1AjVgDS6c6b/2e8e+VBMDImBz Mo1mcRUrnMpcMJkTkflUKn24tLMFps9gTKEjs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:to:content-type:mime-version:subject:date:x-mailer:from; b=ERybYIaLqM9QG5iE0JjJCpkt1QRxSCVFQ+4+g83ReYfZAZURSe847c11ZFhwOUvgFF 2jhJU1rus0TKv/P+7GKGHckG3sf49j0JDUIZe3DYMc023lqcKjcIUhPuj/5M78w0PLN+ rSurqAKz3vNYZwaYMKDptNAiChhpZvUXSLUiM= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by John D. 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EwL8NuTaP+L0mr6UpirxVR3eCotngIiiPYnHnvj6da4=; b=Dc9SnZIWEQMV9R8UXze5jlvUXfPnOR2ApbSBb1T3hCbtGaKA7xECSN0uK0WfCdddqa owvVKPg/tVUeOj8zH1+tPSFfFzTps7GpENftcyuBM/BSqhnwtJjCXlG9AqppJ3Phh4pG iovsTatjg6V55TPGWnDnJf6nbvLgRfiPDGzbs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pselpS+eh82a0djOgdy9nOI4WXIY2AKZhxFKSLmWJ5e+qOcJI3xFeTChXHoDoIv3Qj fARrIgIG8gAlGXkL1zSDJvjbQqw5h4cUWuUvLf/CFKssPakO48AE2CAxtHu3Ug0P4QWK NFBzRAmGUUfLhD1wB1jgojzc8jxzPPeO7hmRs= On Mon, Dec 15, 2008 at 6:50 AM, Terry Lambert <tlambert(a)apple.com> wrote: > > On Dec 14, 2008, at 9:02 PM, "John D." <johndenkar(a)gmail.com> wrote: >> >> Excuse me, but monkey business is taking FreeBSD and Mach, creating a >> hybrid kernel, and crippling the API in a manner that doesn't let >> third-party developers exercise the best of both systems. Is that >> common sense? > > John, step down. > > I am the senior engineer on the Kernel team for BSD, Mike is more senior > than me, and Dean Manages the IOKit team. > > "No" means "No". I'm not questioning your knowledge here nor that of anyone else. I've got no time for it and no interest. Really. I came here asking why the BSD interfaces have been crippled to a certain extent, and that's it. If you don't want to provide a consistent answer it's fine, just don't enter a red herring argument about what makes your actual statements more reasonable than mine, when you are not providing technical facts supporting them. I could care less about your alleged pedigree. If one's professional position and its required knowledge matches his current skillset and reasoning is, again, moot. We might as well move on the question I sent about mbuf structures and NKE ipfilters. Those interfaces are examples of good work you've done there, so congratulations for that one. On other hand. I still think kauth is severely limited (crippled) as it is implemented right now. Check the current NetBSD code which is what you ported to XNU originally and adapt the new changes to XNU (from -CURRENT). Relax. - John Denkar _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by Terry Lambert 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Excuse me, but monkey business is taking FreeBSD and Mach, creating a hybrid kernel, and crippling the API in a manner that doesn't let third-party developers exercise the best of both systems. Is that common sense? John, step down. "No" means "No". -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 14, 2008, at 9:02 PM, "John D." <johndenkar(a)gmail.com> wrote: I am the senior engineer on the Kernel team for BSD, Mike is more senior than me, and Dean Manages the IOKit team. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by John D. 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=J2vzeKknUv8yXUMySBVtwl2R8aZAGffVu+VnOIRaLcM=; b=nt25memjOl1Wm5RW77ol9DuGeI5uKg0VdUX8zjUEpJO4dpD/V96LzMcqY8CgY005V9 1qT7HRXgAvQD3jfHXnu1QdDxfTmxG1fiUPiPIdow5gZJ2X7TIPW8b/J7L4uvSWetDdG2 YSwdCtz0PpSVg91AGc18Tad5gXHFoHO1OrISs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Ry6cFC4Akx+NcTaEeRJkEHP4EWLljDqO3gs77Fm0yKF+inRmyirXYbzSD3961JIGgH gZ2aY9K4ZVlkkGkNgFv91NmxZjuskdC3XDktdKD4ahdVTHoZQgcsCB51db96loT55HI3 Vd8mKX0tDm+z4Dh3dmYp4lfnbh08ejmGh18fU= On Mon, Dec 15, 2008 at 6:15 AM, Michael Smith <drivers(a)mu.org> wrote: > > On Dec 14, 2008, at 9:02 PM, John D. wrote: > >> Excuse me, but monkey business is taking FreeBSD and Mach, creating a >> hybrid kernel, and crippling the API in a manner that doesn't let >> third-party developers exercise the best of both systems. Is that >> common sense? > > When it enables companies to ship billions of dollars worth of hardware to > tens of millions of customers, yes. > > When it facilitates a company building a ground-breaking portable hybrid > computing/telecommunications device, yes. > > When it empowers thousands of third party developers in the form of the > vibrant market for Mac OS, including many products that extend the system in > useful ways, yes. Mike, no offense meant. But you could tell me something I can't read already off Apple's own marketing panflets. I thought this was a technical list. > I realise that you feel that the current state of play is inconvenient to > you, but you really do need to step back and read what Dean and Terry and > others have written in this thread in the context of a much bigger picture > than your own personal desires. All I asked here was information about accessing otherwise crippled interfaces which are available by default to FreeBSD kernel modules. Since the code base is essentially the same, except for some minimal changes and glue code, I would expect some of the interfaces to be available. Anyway, let's take the discussion back to technical grounds, please. I neither have time nor interest on going on the marketing or political mumbo jumbo. If there's a mailing list sponsored by Apple explicitly for that purpose, I will subscribe to it when I need to discuss those matters. - John Denkar _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by Michael Smith 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 14, 2008, at 9:02 PM, John D. wrote: Excuse me, but monkey business is taking FreeBSD and Mach, creating a hybrid kernel, and crippling the API in a manner that doesn't let third-party developers exercise the best of both systems. Is that common sense? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… When it enables companies to ship billions of dollars worth of hardware to tens of millions of customers, yes. When it facilitates a company building a ground-breaking portable hybrid computing/telecommunications device, yes. When it empowers thousands of third party developers in the form of the vibrant market for Mac OS, including many products that extend the system in useful ways, yes. I realise that you feel that the current state of play is inconvenient to you, but you really do need to step back and read what Dean and Terry and others have written in this thread in the context of a much bigger picture than your own personal desires. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by John D. 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=IuMjM6F9nAuPJPeBZ3x1izy/ZHpS2vzCBmgj9EeiIok=; b=N/I3AqPnOi4Jt5ohLSioD7dZeFQUsoGUwHttSTepIET/Qf00WwPp4qVfg8ELMev0b4 vwfovPciV7bfjbZ83aZZosyMvz4NgRiSogPjshX6dbZ6khbOWu8pCsmkDaurw/BjH2H/ rxZmSKaubh5rm2alwUKkZ/9wQTHnFVnf1KPSA= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cHSO9rfRD69mdaZoQrw6WK7jcSn7E/k+zmoHKBp4uYKiq5CUo8kICT6WPMvfELP3TR +/ZaeUEgc8x5CWJWqmb/2yjhAM7860zWkaxJff9ZAWCNHmThFEG0TPhwrFj2L3j/S5G6 e+EbxRg/W2TP4Uesk3NGI+QDy1JcVjN/5XaZk= On Mon, Dec 15, 2008 at 5:33 AM, Dean Reece <dean.reece(a)apple.com> wrote: > 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. Correct me if I'm interpreting your words wrongly, buy did you just say that anyone who steps out of the limited KPI interfaces is illegitimate? That sounds naive. It's not their fault if you have crippled the FreeBSD kernel API. I'm not saying you don't have any legit reasons to do so, but it's a fact that you've done it. Regarding protections to prevent things like memory patching, et al; honestly, the result will be a more crippled set of kernel interfaces and no true feasible or practical improvements. Once your code runs in privileged mode there's simply no way to prevent anything. The only limitation is the skillset and level of complexity required to implement the new counter measures. Hence why I said all those measures are effectively useless in practice. Unless you have a hardware-based mechanism (which can be assured to be tamper proof as well, think of sealed TPM module or alike) validating privileged code changes or firmware, there's no way you can prevent 'unofficial' modifications. Then again, this could be illegal to implement and will be broken as soon as someone has the time, effort and skillset to put on breaking it. -- - John Denkar _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by John D. 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4cgmjMyYNjuqXZvTpPU8xqQtJhwBaHPkCywV38S8EQA=; b=ZELReVfqaNLl9/bi9O+hDE5z7GMlJ66IrMnhIufo//qQTcmLgy4N31VQLtEl2MdkJF sEQzSBHOeGkT6bb6PBR/cof/EJA2qaXblSd3UaEFn72Y45r+Fx6kTx7XMpyfm03tENuk +QY+PbVDdzU1rkGV8nYsvK8ona9PtQmVPMf94= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ST/0beDGsvVBA10akGzPISavWVFjVO+fFkBe47S3EuPAj4NukbS13TA7Z8skvihdXm nJhHe44f9bVxfuIcbM1Vyq6nCR+ZcfrR4TZj9oST8rA4wKLJLPU+wtBlES+/9PMeC9hf fT0JQJWpu7Ueaz0EjErpIK1EvNd93l7yhbOUI= On Mon, Dec 15, 2008 at 5:32 AM, Michael Smith <drivers(a)mu.org> wrote: > Incidentally, users like stable, supported interfaces as well. The sort of > monkey business you're talking about tends to fail spectacularly, and they > don't like that. Typically when something stupid breaks. users come running > and complaining to Apple, despite the fact that it's a third party that's > wilfully ignored both established guidelines and basic common sense. Excuse me, but monkey business is taking FreeBSD and Mach, creating a hybrid kernel, and crippling the API in a manner that doesn't let third-party developers exercise the best of both systems. Is that common sense? - John Denkar _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
by Dean Reece 15 Dec '08

15 Dec '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thanks, - Dean _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Dec 14, 2008, at 7:47 PM, John D. wrote: On Sun, Dec 14, 2008 at 8:33 PM, Terry Lambert <tlambert(a)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(a)lists.apple.com

1 0