DragonFly BSD
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


From: "David P. Reese Jr." <daver@xxxxxxxxxxxx>
Date: Fri, 22 Aug 2003 11:35:58 -0700

On Fri, Aug 22, 2003 at 10:44:11AM -0700, Matthew Dillon wrote:
>     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.

I realized this the hard way and tried to code around it.  My original plan
was to do this work to eventually rip out COMPAT_43 without changing the
native syscall code.  I tried to find all of the cases where I would have
to un-modify userland structures for the code to work.  After doing such
work, I fully realize that it's a shady hack and could be handled more
elegantly with a more comprehensive plan.

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

That would make life much easier.  It looks like you have to do this anyway
in order to implement async syscalls.

>     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!).

This is the whole reason why I'm interested in DragonFly.  Very little
politics, lots of code.

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

I'd like to do as much of the work as possible.  However, I realize that it
may be holding back another project until it is done.  I should have a couple
syscalls separated by the end of the weekend.

> 					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
> :

-- 
   David P. Reese, Jr.                                     daver@xxxxxxxxxxxx



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]