home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5170 < prev    next >
Encoding:
Text File  |  1992-09-07  |  1.7 KB  |  59 lines
  1. Path: sparky!uunet!mcsun!Germany.EU.net!tools!ws
  2. From: ws@tools.de (Wolfgang Solfrank)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: GDB under 386bsd 0.1
  5. Date: 5 Sep 92 19:28:07
  6. Organization: TooLs GmbH, Bonn, Germany
  7. Lines: 45
  8. Message-ID: <WS.92Sep5192807@kurt.tools.de>
  9. References: <1992Sep4.005417.3876@gumby.dsd.trw.com>
  10.     <1992Sep4.153554.4387@cs.few.eur.nl>
  11. NNTP-Posting-Host: kurt.tools.de
  12. In-reply-to: pk@cs.few.eur.nl's message of Fri, 4 Sep 1992 15:35:54 GMT
  13.  
  14. While your fix probably solves this particular problem, the real
  15. fix is to modify the copyout routine to explicitly check for a
  16. write to a write-protected page. Without this the copy-on-write
  17. handling never takes place when the kernel writes data to the user.
  18. E.g. in the following program the data read by the child can be seen
  19. in the parent's data space:
  20.  
  21. char buf[512];
  22.  
  23. main()
  24. {
  25.     switch (fork()) {
  26.     case -1:
  27.         perror("fork");
  28.         exit(1);
  29.     case 0:
  30.         buf[0] = 0;
  31.         if (read(0,buf,sizeof(buf)) < 0) {
  32.             perror("read");
  33.             exit(1);
  34.         }
  35.         return 0;
  36.     default:
  37.         if (wait(0) < 0) {
  38.             perror("wait");
  39.             exit(1);
  40.         }
  41.         write(1,buf,strlen(buf));
  42.         return 0;
  43.     }
  44. }
  45.  
  46. Bill Jolitz included an obviously first try in locore.s, but this
  47. is disabled by a #ifdef notdef (don't know the reasons for this).
  48.  
  49. While I read this code another bug came to my mind. In the
  50. copy{in,out} routines the kernel uses the kernel data segment to
  51. access the user data. This means the user program can e.g. give
  52. the address of some kernel data structure to the read system call
  53. and thus destroy (or otherwise modify :-() its contents.
  54.  
  55. When I'm done testing this I will post a fix. But don't hold
  56. your breath as I'm a little short on time currently.
  57. --
  58. ws@tools.de     (Wolfgang Solfrank, TooLs GmbH) +49-228-985800
  59.