Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Aug 2000 09:38:06 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Theo van Klaveren <t.vanklaveren@student.utwente.nl>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: In-kernel ioctl calls
Message-ID:  <Pine.NEB.3.96L.1000810093239.22790B-100000@fledge.watson.org>
In-Reply-To: <001e01c0020c$d257b3c0$19e55982@student.utwente.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Aug 2000, Theo van Klaveren wrote:

> The first statement issues the read command to the device, I presume. It
> copies the data to an internal (kernel-space) buffer. Next, the internal
> buffer is copyout()ed to ubuf (which is my ioctl buffer), which fails
> because in the case of AudioFS it's in kernel space. 

I've actually run into this problem in a number of places -- specifically,
aio support.  I needed to generate aio requests in kernel, and the calls
were intended to be instantiated only from userland.  The linux emulation
code presumably also jumps through hoops to deal with calls that require
data coming from userland.  This has, I think, a lot to do with the design
of the syscall and implementation of the syscalls.  As mentioned in
another forum a few weeks ago, it also makes authorization hard, as it
happens in many places.

I'd really rather see the calling of syscalls broken out into "service"
and "abi" layers, where the "service" layer implements the service, and
uses struct uio for all argument reads/writes, and the ABI layer is
responsible for setting all that up, but not much else.  This would allow
then ABI layers such as FreeBSD, BSD/OS, Linux, to contain minimal service
implementation, moving all implementation into the service layer, which
would not have to be aware of much in terms of whether arguments came from
{user,sys}space, locking semantics, or authorization.  Now, this is
somewhat far from the current implementation, but I think is a worthwhile
goal.

For ioctls, which are down a few layers in the implementation, maybe we
need to start passing down an explicit "this call is kernel or user
initiated".  There are already situations in, for example, the quota and
extattr code, where a NULL struct cred indicates "authorize as kernel",
which is a somewhat similar issue.  Maybe we need a USERSPACE/SYSSPACE
argument in kernel to calls that may or may not do their own
copyin/copyout.

  Robert N M Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000810093239.22790B-100000>