Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.bugs.4bsd
Subject: Re: exec (really vinifod) can scribble random kernel data
Message-ID: <7747@mimsy.UUCP>
Date: Wed, 29-Jul-87 07:37:20 EDT
Article-I.D.: mimsy.7747
Posted: Wed Jul 29 07:37:20 1987
Date-Received: Fri, 31-Jul-87 02:14:57 EDT
References: <24281@sun.uucp> <1497@ccicpg.UUCP> <24372@sun.uucp>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

>>The same fix should be made in vm_pt.c around line 120.

I had wondered about this too.

In article <24372@sun.uucp> mojo@sun.uucp (Joseph Moran) writes:
-It was not obvious from the original message, but in the first fix the
-SKEEP flag is on for the process being exec'ed all during the calls to
-vgetvm(), xalloc(), and vinifod() from getxfile().  It is my belief
-that the only time vinitpt() will end up calling vinifod() is when it
-is called as a result of getxfile() calling xalloc() calling xlink().

This seems to be true.  Note that xalloc() can twiddle SKEEP itself,
but only if not paging from an inode, in which case XPAGI is not
set and hence xlink will not call vinitpt() anyway.  In other words,
the original change may unnecessarily turn off SKEEP, but so what?

-Another way to attack this problem is to have vinifod() itself set and
-clear the SKEEP flag similar to how it's done above so that it doesn't
-assume anything about the process flags on entry.

Or have vinifod() find the ptes itself.  It could simply redo the
?ptopte() after each call to bmap().  But is it safe to swap the
process before all its ptes are set?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris