At 09:47 AM 12/20/2003, Andrew Brown wrote:
> >> >>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.
Note that, unlike sysctl's, mmrw's use of the address is only fleeting.

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

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

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.