DragonFly submit List (threaded) for 2003-08
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: [PATCH] removing COMPAT_43 from the linuxolator
Hi David! I took a look at it. Not bad, but there is a rather serious
issue with modifying the structure in userspace and that is the fact
that, well, you are modifying the structure in userspace and exposing
your changes to the userland program. Programs will mostly expect these
structures to not be modified by the system call, and it is just luck
that it didn't break anything.
What I recommend you do instead is to separate out the copyin operation
in the native syscall code. This has already been done for a number of
system calls such as nanosleep(), which takes the main system call
entry point as 'nanosleep()', copies stuff in, and then calls
nanosleep1() with in-kernel structures as arguments.
Ultimately I think we will need to do this sort of separation for all
system calls. The idea was bandied about a bit in the FreeBSD lists
a while back but due to infighting I don't think it was ever implemented.
We don't have that problem here (at least not yet!).
If the work is a little more then you have time for I would be happy to
split the work with you, just point out the native syscall functions you
want me to split and I'll split them.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
:In preparation for work on COMPAT_43 (which is almost complete on my end),
:this patch makes COMPAT_LINUX independant of COMPAT_43. Before it is
:submitted, I'd like some feedback.
:
:http://gomerbud.com/daver/patches/dragonfly/linuxolator-compat43-removal.diff
:
:A couple of concerns:
:
: Should I next fix the other emulation layers so that they don't depend
: on COMPAT_43? I don't have any svr4 or ibcs2 binaries to test them with.
: Most of these changes are network related, so I'd need some network
: capable binaries to test with.
:
: This patch was tested with both linux-mozillafirebird and the linux
: rpcinfo binary. Both seem to work just fine.
:
: The sendmsg and recvmsg syscalls SHOULD work. I should have time to test
: them this weekend if need be.
:
: The stat and lstat syscalls SHOULD work, however I have not had time to
: build linux binaries in order to test them. Aren't these obsoleted in
: more recent linux software by the stat64 and newstat syscalls?
:
: Instead of using the obsoleted socket syscalls, we use an extra copyin
: and copyout to modify a structure in userspace possibly before and
: possibly after the native syscall function is called. This shouldn't
: slow things down too much. If need be, I can tweak this a bit to try
: and speed them up.
:
:--
: David P. Reese, Jr. daver@xxxxxxxxxxxx
:
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]