On Aug 24, 2012, at 1:16 PM, Evan Lojewski <
email@hidden> wrote:
> I think a good question to ask here is *why* you want to do an
> integrity check. Do you just want to make sure that the Kext hasn't
> been corrupted? Additionally, if the Kext is loading from a prelim led
> kernel or cache, the binary itself may get modified.
>
> Evan Lojewski
>
> On Aug 24, 2012, at 1:08 PM, Ken Hornstein <
email@hidden> wrote:
>
>>> You seem to be drawing conclusions based on writing a BSD filesystem
>>> kext (?) which is not the general case, and certainly has a different
>>> operating environment than 99% of kexts (which are IOKit kexts,
>>> match asynchronously with respect to the root filesystem and each
>>> other, and cannot in general call into the BSD side of the kernel
>>> early in boot without panicking)
>>
>> Well, yeah, that's my experience, and I hope I've never presented myself
>> as the be-all expert when it comes to MacOS kernel extensions because
>> obviously I'm not.
>>
>> My original point was that you can definitely access filesystems
>> from kexts, but I was under the impression that kext loading was
>> handled exclusively by kextd and friends and obviously everything
>> will be up and running by that time. As you've pointed out, that's
>> not a valid assumption; I learned something new today.
>>
>> It occurs to me that if your kext is loaded before the root filesystem is
>> mounted you could do somet goofy stuff like have a thread wait around until
>> it is available, but that probably falls under "here be dragons".
>>
>> --Ken
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Darwin-kernel mailing list (
email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden