Messages in this thread |  | | | Subject | Re: scsi-destroyer.c to come... | | Date | Sun, 23 Jul 2000 18:12:51 -0400 | | From | Horst von Brand <> |
| |
Aaron Sethman <androsyn@ratbox.org> said: > On Sat, 22 Jul 2000, David Luyer wrote: > > So what? > > > > It is _much_ easier to do "cat </dev/zero >/dev/sda" > > and about as likely to be effective.
> But how often is a program with a bug in it likely to execute this > command?
Scripts, run by root, which are then given the wrong output file? Does happen... Linus himself fried a partition table by dialing /dev/hda once ;-)
> Lets say some program has a buffer overflow somewhere and it > ends up clobbering the section of memory that holds the bits for the > ioctl. Suddenly your data is gone and your left clueless. My question is > what functionality are you going to lose by have some sanity checking in > the kernel? Yes I know you can fiddle with /dev/mem etc..but this is know > where near as likely to be triggered by a buggy program now is it?
Never heard of anything like that happening. Or an accidental buffer overflow reflashing a BIOS, or the SCSI controller's BIOS, or anything like that. The real (much more frequent, that is) problems are quite mundane: Overflows/following the wrong pointer inside the kernel has scribbled over the disk and forced two or three complete reinstalls here during 2.3, core files generated by overflows have clogged / on occasion, 2.4.0-testX NFS doesn't work right with Red Hat 6.2 init scripts/programs (nfslock complains and doesn't start, and running NFS this way screws up Solaris 2.6 machines serving files so they have to be rebooted), a couple of CDs I've got give SCSI I/O errors on my SS4, and from then on more and more processes freeze until in some 2 minutes the machine is dead. Those are problems that do matter to me, not a theoretical way to kill a disk, given that there are literally thousands of ways of doing so already. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |