Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!darwin.sura.net!haven.umd.edu!uunet!mcsun!Germany.EU.net!tools!ws
From: ws@tools.de (Wolfgang Solfrank)
Newsgroups: comp.unix.bsd
Subject: Re: GDB under 386bsd 0.1
Date: 5 Sep 92 19:28:07
Organization: TooLs GmbH, Bonn, Germany
Lines: 45
Message-ID: <WS.92Sep5192807@kurt.tools.de>
References: <1992Sep4.005417.3876@gumby.dsd.trw.com>
<1992Sep4.153554.4387@cs.few.eur.nl>
NNTP-Posting-Host: kurt.tools.de
In-reply-to: pk@cs.few.eur.nl's message of Fri, 4 Sep 1992 15:35:54 GMT
While your fix probably solves this particular problem, the real
fix is to modify the copyout routine to explicitly check for a
write to a write-protected page. Without this the copy-on-write
handling never takes place when the kernel writes data to the user.
E.g. in the following program the data read by the child can be seen
in the parent's data space:
char buf[512];
main()
{
switch (fork()) {
case -1:
perror("fork");
exit(1);
case 0:
buf[0] = 0;
if (read(0,buf,sizeof(buf)) < 0) {
perror("read");
exit(1);
}
return 0;
default:
if (wait(0) < 0) {
perror("wait");
exit(1);
}
write(1,buf,strlen(buf));
return 0;
}
}
Bill Jolitz included an obviously first try in locore.s, but this
is disabled by a #ifdef notdef (don't know the reasons for this).
While I read this code another bug came to my mind. In the
copy{in,out} routines the kernel uses the kernel data segment to
access the user data. This means the user program can e.g. give
the address of some kernel data structure to the read system call
and thus destroy (or otherwise modify :-() its contents.
When I'm done testing this I will post a fix. But don't hold
your breath as I'm a little short on time currently.
--
ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800