>> 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.
>
>Right.  I mean, it could be a valid kernel address, but just point to 
>the wrong data.  Or, it could be a userspace address, in which case you 
>need to use copyin/copyout, not kcopy().

i've got two pointers.

one may or may not be a valid kernel pointer.  i can't tell.

the other may be a pointer into userspace or a pointer into kernel
space.  i can tell which kind it is, and if it's the latter, i'm
perfectly willing to assume that it's valid.

if the second pointer is into userspace, i use copyin()/copyout() and
i get EFAULT when one of the pointers is bad.  copyin()/copyout()
don't differentiate where the fault was, but i don't care.

in the case where i have a pointer to kernel space, i'm mainly
concerned that the first pointer might not be good.  at first i though
that asking uvm_kernacc() would help, but it doesn't.  then i found
kcopy() and it sounded like exactly the thing.  except that causes
panics.

i'd like to be able to allow the user process to ask sysctl to
instrument an area of memory starting at the address known by symbol
"fribit" and for length "m".  i'd like either to be able to say
beforehand that that area is acceptable (and either return success or
failure to the create request), or later on when the node is accessed
(allowing the create to succeed all the time, but then failing
accesses when they occur) which ultimately makes more sense since it
might be a valid address range when the create occurred but become
invalid later.

ideas?

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