I couldn't have said it better myself.
I, for one, think the patch needs to go in. Reading Andre's real
explanation of what the patch were to do, it only seems like the 'sane'
thing to do. If something isn't following spec, it shouldn't be allowed to
pass, BOTTOM LINE. Adding in the compiletime option gives that power back,
(which would [presumably] be used for development, etc.) so what is
everyone complaining about? Andre knows best on this issue; I will stand
behind him on it.
Kelsey Hudson khudson@ctica.com
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
On Fri, 21 Jul 2000, Mike A. Harris wrote:
> On Thu, 20 Jul 2000, Andre Hedrick wrote:
>
> >The object is to protect this from happening even if you are ROOT or have
> >stolen ROOT priviledges.
> >
> >Does this help explain the issue or should I provide a "disk2brick.c"
> >program to make the point clearer? This will vaporize a drive to the
> >replacement level. Yes you can to that today!
>
> Great... And next thing we'll know that there are trojan's out
> there, that fry hard disks. Could be in the next upload to
> redhat contrib, and in source form. How many people actually
> audit contrib sources (or any for that matter) before building an
> app? I know nobody. A trojan wiping data, and one FRYING the
> hard disk permanently are two different matters entirely.
>
> Physical damage of the computer IMHO is in the kernel's best
> respects to prevent. Especially if there is never any use of
> having the capability to begin with. What I'm getting from this
> is that 5 to 12 bytes of data sent to the HD can permanently fry
> it. If this is correct, then we need better standards indeed. I
> would think any destructive action like this would require a
> jumper being flipped first.
>
> So, please fix the problem as you planned for sure. Toss
> grenades to clear a path if you have to. ;o)
>
> This brings up an interesting idea... Is it not also easily
> possible to fry the motherboard BIOS, and other PCI/ISA card
> BIOS's by mapping their IO regions from rootland and then tossing
> the right magic at them? What about the firmware in my CD
> writer? I upgraded it once and it never required flipping any
> jumpers.
>
> If any of this info can be reverse engineered or obtained by evil
> minds, our computers are TOAST. I remember back 5 years or more
> ago, anti-viral FAQ's saying "It is IMPOSSIBLE for a virus to
> permanently damage the hardware in your computer." Now I'm not
> so sure. The way I see it, not only is it possible, but it is
> possible with the hard disks, motherboard BIOS, modem BIOS, Video
> BIOS, CDwriter firmware, and likely various other peripherals.
>
> Since we are in "open source" land, it is likely that someone
> will reverse engineer the means to do all of the above and
> release open source code to do so. Should that code ever exist,
> our computers are highly at risk of being damaged and a lot of
> money going down the tubes.
>
> I can see hardware vendors getting sued for making hardware that
> is software damageable. I know I'd be seeing a lawyer if some
> virus fried my HD or writer...
>
> So I think what you're stating here Andre is a good thing, one
> that needs to be fixed indeed.
>
> Keep up the good work, and don't let the pessimists fry your
> ideas as well as your hard disks.
>
> Take care,
> TTYL
>
>
> --
> Mike A. Harris Linux advocate
> Computer Consultant GNU advocate
> Capslock Consulting Open Source advocate
>
> ... Our continuing mission: To seek out knowledge of C, to explore
> strange UNIX commands, and to boldly code where no one has man page 4.
>
>
> -
> 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/
>
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:17 EST