home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / next / programm / 5938 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!ogicse!news.u.washington.edu!news
  2. From: mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Re: How to PANIC a NeXT (mach kernel bug )
  5. Message-ID: <MS-C.715477205.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU>
  6. Date: 2 Sep 92 23:40:05 GMT
  7. Article-I.D.: Tomobiki.MS-C.715477205.1103527590.mrc
  8. Sender: news@u.washington.edu (USENET News System)
  9. Organization: University of Washington
  10. Lines: 30
  11. In-Reply-To: <1992Sep2.131055.25827@jhunix.hcf.jhu.edu>
  12. Content-Type: TEXT/PLAIN; charset=US-ASCII
  13. To: Christopher D Audley <audley@jhunix.hcf.jhu.edu>
  14. Mime-Version: 1.0
  15.  
  16. I believe that it is perfectly reasonable to claim that it is a bug in
  17. the kernel if the kernel crashes just because some user consumed all
  18. of a particular resource.
  19.  
  20. Bug #1: the user should not have been allowed to consume the entire
  21. resource.  There should be a high-water mark for individual user use.
  22. If the resource is something that the kernel also needs, there should
  23. also be a high-water mark for total user use beyond which only the
  24. kernel or privileged users can tread.  Disk space has the latter type
  25. of high-water mark.
  26.  
  27. Bug #2: the kernel should not have crashed when the resource ran out.
  28. It should have rejected the fatal attempt to get the resource.  If it
  29. felt really nasty, it could have killed the process (which would have
  30. freed things up quite nicely!).
  31.  
  32. Bug #3: it is a bug in the minds of `propeller heads' (to quote Steve
  33. Jobs) that it is EVER anything other than a bug for a kernel to crash.
  34. It may be a bug in the hardware.  It may be a bug in the software.  It
  35. can be malicious physical damage (induced hardware bug).  But no
  36. kernel should crash because of the actions of an unprivileged user
  37. program.
  38.  
  39. Back in prehistoric days (before UNIX), we actually tried to make
  40. operating systems that would not crash even with the most abusive user
  41. programs running.  We succeeded, too.  It is embarassingly easy for an
  42. unprivileged user to crash even so-called `secure' UNIX systems,
  43. including in ways that cause filesystem damage.  This is an Achilles'
  44. Heel, and one that should not be tolerated in a `UNIX for the masses'
  45. system as NeXT claims to be.
  46.