lkml.org 
[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What's wrong with IDE patch and what proper solution shouldbe...
Steve VanDevender wrote:
>
> Mike A. Harris writes:
> > >Yikes! This way lies madness (at least for SCSI). Removing the
> > >equivalent of the sg interfaces would reduce Linux to a platform much
> > >like Windows where every single new SCSI device probably needs to
> > >provide its own kernel modifications/modules/driver to allow
> > >device-specific apps to talk to it.
> > >
> > >Right now, you can write (for example) an Iomega Jaz utility without
> > >any kernel futzing at all. Contrast this with Windows where it seems
> > >necessary to always install a new driver.
> > >
> > >Don't go there.
> >
> > Part of the kernel's JOB is to arbitrate hardware access. If we
> > extend your argument, we take out all hardware drivers and
> > replace them with userland applications and libraries. Then we
> > end up with MSDOS.
>
> Oh please. The point of a standard protocol is to make it possible to
> interchange devices from any number of manufacturers on the same
> interface. That way the kernel need have only a SCSI driver, not a
> Brand X SCSI driver, a Brand Y SCSI driver, a Brand Z SCSI driver, ad
> infinitum. We should have standard drivers to support standard
> protocols, not a huge mess of drivers for all sorts of nonstandard
> hardware.
>
> So apparently the story so far (as best as I can reconstruct it from
> Andre's unrelentingly incoherent rants) is that some possible ATA/IDE
> commands that aren't currently defined in the ATA/IDE specification have
> been appropriated by some manufacturers to do certain very dangerous
> things. Apparently these "can and may" (to use Andre's
> self-contradictory phrasing) void your warranty if issued to the drive,
> silly as that sounds.
>
> I'm sure the manufacturers would love to blame all those OSes out there
> for damaging their drives, when it's the manufacturer's own damn fault
> that they've made drives that can be turned into metal-and-plastic art
> objects with software commands. What if Intel said that executing
> undocumented opcodes could void your warranty and destroy your
> processor? Would we be putting code into the kernel to try to prescan
> all executables for the self-destruct opcodes? No, the smart people
> would be fleeing from Intel.
>
> I think we need to find out which manufacturers were stupid enough to
> make drives that can be made to self-destruct, and stop buying those
> drives.
>
> Of course, there was the good point that despite all the hullaballoo, no
> one has actually confirmed that you can destroy drives this way.

I know it's true. I have run the disk-destroyer program. Twice.

I compiled a 2.4.0-test5-pre2 kernel with an earlier version of Andre's
patch and actually ran the disk-destroyer program as a test. Andre
specifically did not include the fry-your-drive codes in the test
program, but on the first try it sucessfully hosed the MBR and partition
table (my /dev/hda1 was/is swap, so I don't know how much of that went
bye-bye too). After a fresh install of Red Hat 6.2, I (glutton for
punishment that I am) recompiled 2.4.0-test5-pre2 with the latest patch
(has it been restored to www.kernel.org?) and now my system can survive
the disk-destroyer (The drive still makes god awful noise when run, but
no permanant damage occurs). I captured the output of the disk-destroyer
and sent it to Andre with a list of my hardware (mobo & drive models) so
he could further refine the patch. I wish more people would get off
their high horses and help out in any way they can. I am a lowly
installation support technician an not a kernel-god who dreams code in
their sleep, but I will help in any way I can to improve Linux as a
whole. Will you?

Chris Kloiber

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.069 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site