In article <20050711144828.GH28480@gallia.cubidou.net>,
Quentin Garnier  <cube@cubidou.net> wrote:
>-=-=-=-=-=-
>
>On Mon, Jul 11, 2005 at 04:35:47PM +0200, Wolfgang Solfrank wrote:
>> >To properly fix netbsd32_wait4(), the only thing that would be needed is
>> >a slighly smarter copyin()/copyout() that would check if the supposedly
>> >user address is actually a kernel address or not, and in the former case
>> >only do a memcpy().  I don't know if it easy to do that, even if it ends
>> >as a set of MD implementations.  I do know that it wouldn't be only
>> >useful for compat_netbsd32, though.
>> 
>> I'm not sure that I do understand what you are trying to do here.
>> 
>> However, it sounds that you are trying to allow copyin/copyout to silently
>> access kernel memory as source/destination respevtively.  Apart from 
>> Christos'
>> comment regarding the possibility of determining a kernel from a user 
>> address,
>> this is not a good idea.  copyin/copyout is not only for transferring data
>> between the user and kernel domain, but is also used to check for access
>> protection.  IIUC what you are proposing, this would open up serious 
>> security
>> holes...
>
>You're right: even if it was possible to make sure an address is for
>the kernel or for the userland, it would be very hard to make sure the
>kernel itself requested the copy to/from its own space;  it would have
>meant passing a flag of some sort, which is basically what I do passing
>a function.
>
>At some point (I'm still using it for one syscall in my source tree) I
>had the idea of passing a flag rather than a function, which would be
>UIO_SYSSPACE or UIO_USERSPACE.  Then the dosyscall() routine would
>either memcpy() or copyin/out depending on the value of that flag.  But
>that affects the native path probably more that using a pointer to a
>function.

I think that it is easier to have all the dosyscall() functions to assume
that the copyin has been done for them and that the memory of everything
they access is already in kernel space, except in the few cases where it
does not make sense to do so (and we can name them differently to make
sure that there is no confusion). This way we will be able to get rid
of a lot of the stackgap massaging which has security problems.

christos