home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / next / programm / 5957 < prev    next >
Encoding:
Text File  |  1992-09-03  |  3.3 KB  |  67 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!gatech!destroyer!ubc-cs!unixg.ubc.ca!kakwa.ucs.ualberta.ca!atlantis!splunge!royce
  3. From: royce@splunge.uucp (Royce Howland)
  4. Subject: Re: How to PANIC a NeXT (mach kernel bug )
  5. Message-ID: <1992Sep3.131255.14005@splunge.uucp>
  6. Organization: Ashley, Howland & Wood
  7. References: <MS-C.715477205.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU>
  8. Date: Thu, 3 Sep 1992 13:12:55 GMT
  9. Lines: 56
  10.  
  11. mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
  12.  
  13. >I believe that it is perfectly reasonable to claim that it is a bug in
  14. >the kernel if the kernel crashes just because some user consumed all
  15. >of a particular resource.
  16.  
  17. >Bug #1: the user should not have been allowed to consume the entire
  18. >resource.  There should be a high-water mark for individual user use.
  19. >If the resource is something that the kernel also needs, there should
  20. >also be a high-water mark for total user use beyond which only the
  21. >kernel or privileged users can tread.  Disk space has the latter type
  22. >of high-water mark.
  23.  
  24. >Bug #2: the kernel should not have crashed when the resource ran out.
  25. >It should have rejected the fatal attempt to get the resource.  If it
  26. >felt really nasty, it could have killed the process (which would have
  27. >freed things up quite nicely!).
  28.  
  29. >Bug #3: it is a bug in the minds of `propeller heads' (to quote Steve
  30. >Jobs) that it is EVER anything other than a bug for a kernel to crash.
  31. >It may be a bug in the hardware.  It may be a bug in the software.  It
  32. >can be malicious physical damage (induced hardware bug).  But no
  33. >kernel should crash because of the actions of an unprivileged user
  34. >program.
  35.  
  36. >Back in prehistoric days (before UNIX), we actually tried to make
  37. >operating systems that would not crash even with the most abusive user
  38. >programs running.  We succeeded, too.  It is embarassingly easy for an
  39. >unprivileged user to crash even so-called `secure' UNIX systems,
  40. >including in ways that cause filesystem damage.  This is an Achilles'
  41. >Heel, and one that should not be tolerated in a `UNIX for the masses'
  42. >system as NeXT claims to be.
  43.  
  44. Excellent points, and I would extend them to other aspects of the
  45. environment as well, such as the Window Server.  It's frustrating to
  46. work with certain software packages that can cause the Window Server
  47. to crash and wipe out ones entire login session.  This should not be
  48. tolerated, whether it's the result of a bug in the software package
  49. or in the Window Server.
  50.  
  51. A primary goal of a protected, multi-user, multi-tasking OS is to
  52. isolate processes from each other, so if one causes trouble, the
  53. others are not affected.  Of course, this goal is defeated if there's
  54. a problem with one of the high-level system processes (who watches the
  55. watchers).
  56.  
  57. And no, I'm not pointing the finger at any particular software.  The
  58. vendor of one package I have that had this Window Server problem has
  59. provided pretty swell support so far, sending up a version that hasn't
  60. clobbered my machine since the update (although admittedly I haven't
  61. used the package as much since the update).
  62. -- 
  63. Royce Howland   --   Everything is IMHO   |  "I can eat enormous quantities
  64. royce@splunge.uucp        (NeXTMail OK)   |   of ice-cream without being sick,
  65. or kakwa!atlantis!splunge!royce           |   Mrs. S-C-U-M."
  66. C86Net: Mr._Neutron@RT.Alta               |   --Mr. Neutron
  67.