>> >>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.

>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.

>>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.

>If the address is from a user-process, you can't trust it at all.
>As I've said before, that shouldn't be allowed.

rm /dev/*mem

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."