October 2008 - Darwin-kernel

Re: xnu-1228.7.58 build failure
by Shantonu Sen 05 Oct '08

05 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Shantonu Sent from my MacBook On Oct 4, 2008, at 8:10 PM, Michael Reeves wrote: _______________________________________________ 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.… ctfconvert is never fatal to the overall build. Your issue is somewhere else. Please find the compiler invocation error in your build log Has anyone gotten xnu-1228.7.58 to build with darwin tools? I keep getting ERROR: ctfconvert: failed to initialize DWARF: DW_DLE_ELF_STRPTR_ERROR 30 a call to elf_strptr() failed trying to get a section name I am building from 10.5.5. _______________________________________________ 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/ssen%40apple.com This email sent to ssen(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

xnu-1228.7.58 build failure
by Michael Reeves 05 Oct '08

05 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer; b=VKCwZy7K3fS9ikuYPw9kRzJkWDNAppQO0AB1Msxo+J60wJBmMVG2je2kq6CxkBTfvDglge8ZJwdnCfD2S+FHsFmQu3qEK0eTAGJD1xgs1Sz9jkaQ1t7nCXA2EIY8jYughczRw0I5uZC0xLxBIY/FzAGc50EXqp/vh0tzXqQ9DqU= ; Has anyone gotten xnu-1228.7.58 to build with darwin tools? I keep getting ERROR: ctfconvert: failed to initialize DWARF: DW_DLE_ELF_STRPTR_ERROR 30 a call to elf_strptr() failed trying to get a section name I am building from 10.5.5. _______________________________________________ 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

MLock errors on Intel 8-core systems
by Tony Scaminaci 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=aGoSlXJ6qqrW8fl3Txjb3H2COlCkG7AB7aooYOehVRdMiwvVZcdfI616bExRWht4Q+F/uYgo286eVyMX4B7GwTOnc6ge4i56uc93vr2dmHPOEM+XwJfpWZyKMhxnjs9wWs4Lg5aUe7LbvDp/gAB6cnjH4L2r52oWxMBAgBvWqRQ=; _______________________________________________ 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: Register a task's exception port from a kext
by Michael Cashwell 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 3, 2008, at 10:51 PM, nicolas vide wrote: Actually it means they will be more stable over the long-term. -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.… On Sat, Oct 4, 2008 at 1:52 AM, Quinn <eskimo1(a)apple.com> wrote: Specifically, if you link against the entire kernel Just to be sure, when you say link against the kernel, that means building a new kernel with my IOService built-in? No, it means specifying in your kext's property list (Info.plist) in Xcode that you want access to interfaces outside of the KPI. But doing that means your KEXT is bound to a specific kernel version and even minor updates may prevent it from loading. See: <http://developer.apple.com/documentation/Darwin/Conceptual/KEXTConcept/KEXT… > I don't know if it is right but I have the feeling that Apple tries to prevent as much as possible kext's accesses to the kernel functions & data. I am neither a driver person nor a kernel programmer but I played a little with Windows and FreeBSD and I could directly access to processes data structures for example: It is ease to hide a process just by modifying kernel data from a dynamic loadable driver. Obviously, this is a big advantage to prevent anyone to play with kernel internals data, however it means that third party software like anti virus software or monitoring tools will suffer of performance and security issues, right ? In a sense, yes, Apple (not that I can speak for them in any way) does want to limit 3rd part access to parts of the kernel. But the advantage to doing so is not as you've stated above. The reason they want to do that is the same reason any API exists: having a defined interface (for data and functions and for the semantics of using them) means the underlying implementation can change to support new hardware or to improve performance while not breaking existing code. If the entire content of the kernel is exposed and used equally by third parties it becomes almost impossible to change or improve anything because someone somewhere will have relied directly on the old architecture. Apple's KPI is what they intend to support long-term. Developers that stick to it will have less headaches from one release to the next than those who access everything directly. If you have a need for some interface that is not part of the KPI Apple would like to know about it. They aren't unreasonable. It's just they want to be able to improve the kernel over time and having every internal detail exposed equally as an interface we should use undermines their ability to do so. I've worked on Mac OS X and Linux drivers and I personally view Linus's adamant disdain for having a KPI in Linux as nothing more than laziness. It's easier for them but it causes me extra work every month to keep my code current. I have drivers under Darwin that have worked since 10.3 and still work today. I've not had a similar experience with Linux. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Address range returned by malloc
by Michael Smith 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 4, 2008, at 1:40 PM, Greg wrote: uintptr_t, if you must. = 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.… You will be very unhappy if you use a 32 bit integer type to contain a kernel pointer in SnowLeopard. Oh dear, now that you mention it I do vaguely remember something about that... I should keep up with the times shouldn't I? Thanks for pointing that out! :-p This email sent to site_archiver(a)lists.apple.com

1 0

Re: Address range returned by malloc
by Greg 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 4, 2008, at 4:16 PM, Terry Lambert wrote: - Greg _______________________________________________ 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.… The short answer is that if you do pointer math on an address above 2G in a signed it, it will subtract rather than add, and you will get the wrong address. Don't do that. The longer answer is that, as an architectural detail, Intel processors expect high bits not current supported to be set instead of cleared, so the compiler sign extends pointers on conversion from integsr before assignment. In both cases, you are getting luck because of the simplicity of your example. No pointer math is occurring in my code, I'm just converting it from unsigned to signed and back, so I'm hoping, as Jeff Stearns pointed out, that this shouldn't ever be a problem on a 32-bit kernel (right?). However, thanks for the warning on the pointer math, that sounds like something I should generally be aware of. In any event, it doesn't matter if I say this because there are over 15,000 google hits on the information: google the terms: SnowLeopard kernel 64bit. You will be very unhappy if you use a 32 bit integer type to contain a kernel pointer in SnowLeopard. Oh dear, now that you mention it I do vaguely remember something about that... I should keep up with the times shouldn't I? Thanks for pointing that out! :-p This email sent to site_archiver(a)lists.apple.com

1 0

Re: Address range returned by malloc
by Terry Lambert 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 4, 2008, at 3:29 PM, Terry Lambert wrote: unsigned int a = 4294967295; // 2^32-1 int b = (int)a; unsigned int c = (unsigned int)b; printf("%s\n", a == c ? "equal" : "not equal"); -- 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 Oct 4, 2008, at 12:56 PM, Greg <greg(a)kinostudios.com> wrote: Kernel virtual address space for a 32 bit kernel is limited to 32 bits. Pointers are NOT signed values, so do not store the returned pointer into a signed integer, or you may truncate it to 31 bits and overwrite/access something in lower memory than your allocation actually occurred when you go to use it. This would be Bad(tm). Thanks Terry, and I searched online and found that it appears that Apple will continue to use a 32-bit kernel (I hope). I'm aware that void* is unsigned, but I wasn't sure if converting that to a signed type and then back again would lose information. For example this program (with gcc -O0) displays "equal": So what's going on? It doesn't appear to lose any information here. The short answer is that if you do pointer math on an address above 2G in a signed it, it will subtract rather than add, and you will get the wrong address. Don't do that. The longer answer is that, as an architectural detail, Intel processors expect high bits not current supported to be set instead of cleared, so the compiler sign extends pointers on conversion from integsr before assignment. In both cases, you are getting luck because of the simplicity of your example. In any event, it doesn't matter if I say this because there are over 15,000 google hits on the information: google the terms: SnowLeopard kernel 64bit. You will be very unhappy if you use a 32 bit integer type to contain a kernel pointer in SnowLeopard. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hard links to directories
by Terry Lambert 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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: Address range returned by malloc
by Greg 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 4, 2008, at 3:29 PM, Terry Lambert wrote: unsigned int a = 4294967295; // 2^32-1 int b = (int)a; unsigned int c = (unsigned int)b; printf("%s\n", a == c ? "equal" : "not equal"); So what's going on? It doesn't appear to lose any information here. No worries, this is not occurring. :-) - Greg _______________________________________________ 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.… Kernel virtual address space for a 32 bit kernel is limited to 32 bits. Pointers are NOT signed values, so do not store the returned pointer into a signed integer, or you may truncate it to 31 bits and overwrite/access something in lower memory than your allocation actually occurred when you go to use it. This would be Bad(tm). Thanks Terry, and I searched online and found that it appears that Apple will continue to use a 32-bit kernel (I hope). I'm aware that void* is unsigned, but I wasn't sure if converting that to a signed type and then back again would lose information. For example this program (with gcc -O0) displays "equal": If this value is intended to be communicated to user space, consider using a sized type capable of storing either a 32 or 64 bit pointer, such as user_addr_t or uint64_t. This is normally discouraged, since the likely reason for wanting to do it is because you intend to pass the pointer back into the kernel later, and that would ne a gaping security hole. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Address range returned by malloc
by Terry Lambert 04 Oct '08

04 Oct '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Kernel virtual address space for a 32 bit kernel is limited to 32 bits. -- 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 Oct 4, 2008, at 12:10 PM, Greg <greg(a)kinostudios.com> wrote: When you call OSMalloc, IOMalloc, kern_os_malloc, or any of the other mallocs in the kernel, I'm fairly sure I've read that they all eventually call the same low-level malloc function in the kernel (vm_page_alloc() I believe). My question is what range is this address usually in? Is it reasonable to assume, given the amount of memory used by the kernel in RAM, that it will be less than the maximum value of a signed 32- bit integer, even on 64-bit systems? Or is this not a safe assumption at all? Pointers are NOT signed values, so do not store the returned pointer into a signed integer, or you may truncate it to 31 bits and overwrite/ access something in lower memory than your allocation actually occurred when you go to use it. This would be Bad(tm). If you need a generic pointer type, do not use an integer, use void *. If you absolutely must use an integer type to do math (for example, for a byte count rather than an element count in pointer math), then the appropriate type is intptr_t (which is unsigned). If this value is intended to be communicated to user space, consider using a sized type capable of storing either a 32 or 64 bit pointer, such as user_addr_t or uint64_t. This is normally discouraged, since the likely reason for wanting to do it is because you intend to pass the pointer back into the kernel later, and that would ne a gaping security hole. This email sent to site_archiver(a)lists.apple.com

1 0