Subject: Re: kcopy()
To: Matt Thomas <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 12/20/2003 17:21:27
>> >> >>my reading of the kcopy() man page made me think that i could pass it
>> >> >>a "src" pointer and a "dst" pointer, and it would return EFAULT if
>> >> >>either of the pointers were invalid.
>> >> >>
>> >> >>instead, i'm getting kernel panics.
>> >> >>
>> >> >>is there a better interface for copying from place to place when you
>> >> >>don't know the exact disposition of the pointers (so i can't really
>> >> >>use memcpy())?
>> >> >
>> >> >Who is giving you pointers you can't trust? That sounds like a broken
>> >> >interface.
>> >>the kernel, device drivers, lkms, and some users. i don't trust
>> >>everyone and i'd like not to have to trust anyone.
>> >The first 3 can be wholely trusted. The last can't be trusted at all.
>>um...and in the presence of bugs? i'd prefer to take the other path
>>and simply not trust anyone.
>You should assume the kernel is bug free. Though sprinkling KASSERT and
>KDASSERT to make sure things are as you expect would be good. Kernel code
>is always trusted to be correct.
>> >And really, you should NEVER accept a kernel address from a user process.
>> >That is a violation of the user-kernel schism.
>>yet this is precisely what happens when a process reads from kmem. an
>>address in kernel space is given (which might be invalid) along with
>>an address in user space (which might also be invalid), yet mmrw()
>>manages to cope. the only problem from my point of view is that
>>mmrw() is in md code and i'm not.
>That's MD code and has the ability to use faultbuf to recover from failures.
i know it's md code. kcopy() is also md code. copyout() is also md
code. the difference is that mmrw() and copyout() manage not to panic
when used. kcopy() panics.
>Note that, unlike sysctl's, mmrw's use of the address is only fleeting.
actually, sysctl doesn't continuously read from the same address. it
only happens when someone requests the data from a particular node.
the fact that it has it recorded is somewhat irrelevant.
it's really no different from me having an address in the kernel and
periodically reading from it via /dev/kmem. it works most of the
time, but if it doesn't, the kernel doesn't panic. it just tells me
it didn't work.
>> >>just because you trust that the pointer you give me is valid doesn't
>> >>mean i trust you to give me a valid pointer, and if i keep the pointer
>> >>for a few hours, will it still be valid?
>> >If it's given to you from another part of the kernel, you have to
>> >trust they won't go away and if they do go away, you will be informed
>> >ahead of time.
>>that's the ideal situation, yes, but being paranoid, i don't expect
>>everyone to play by those rules.
>You have to expect kernel code to play by the rules. To do otherwise
>is to not trust your kernel at all. That leads to madness. Kernel
>code may be incorrect but then that means there is a bug which will be
then i expect kcopy() not to cause a panic.
incidentally...if i can always know that the kernel is bug-free and
thereby know that all pointers to kernel address space are valid, why
is there a need for kcopy()?
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."