On Fri, Jul 21, 2000 at 05:41:16AM -0400, Mike A. Harris wrote:
> >> Alright, actually, after having a cup of coffee (most of which ended up
> >> on my keyboard :( ), I fully agree with our poor misunderstood friend
> >> Andre. If something is providing access to something at a protocol level,
> >> it is its job to make sure that the protocol is not violated.... imagine a
> >> TCP/IP stack that let you send invalid packets, that wouldn't go over too
> >> well.
> >
> >Of course you can send invalid TCP/IP packets using the network stack in
> >Linux. You can send any packets.
>
> An invalid TCP/IP packet however does not permanently destroy the
> ethernet card, no matter how badly it is screwed up. Nor does it
> fry anything else.
True.
> IMHO, if something violates a standard in some way in kernel, it
> should be fixed if for no other reason than that.
There is nothing in kernel that would violate the standard. There is
code that lets you send invalid commands to the drive, if you really
want to.
The disk-destroyer.c example only overwrites the master boot sector with
zeroes. This isn't a violation of any standard.
Also, unless the drive has very broken firmware, it shouldn't fry itself
when given invalid commands. The drive itself would have to violate the
spec to be allowed to do that in the first place.
If it was the kernel, that under some unusual pattern of usage would
emit an invalid IDE command, then it'd be a serious bug.
But if it just lets root emit an invalid IDE command, while the root has
to know what he's doing, because he needs to write a C program for that,
then it's just a feature that allows him to screw himself. But there are
many like that in the kernel.
> If something
> is a potentially dangerous, and lesser used feature that is added
> to the kernel, it should be CONFIG_SOMETHING so that it isn't
> there if it isn't needed.
Ok, why not. But I don't see any reason in inspecting every call to the
HDIO_DRIVE_CMD ioctl checking the input parameters for correctness.
If the root wants to be paranoid, he can switch the feature off.
> What about
> the case where root DOES NOT want to destroy the disk, and doesnt
> want something else to be able to do so easily either?
As said before, removing the ioctl doesn't make destroying the disk
much tougher. The program to do it would be about ten to twenty lines
longer.
> I think that Andre's idea is right on the money and have yet to
> see a single even remotely good argument against it. If the
> current behaviour violates a standard, then it should be
> fixed.
It doesn't violate anything. It allows the root to do it if he wants to.
> Losing data is one thing, losing hardware is
> another. Any feature the kernel can give to make physical
> hardware destruction impossible or much more difficult is a MAJOR
> plus in my opinion. I think that our machines have all too much
> hardware in them that is software destroyable nowadays.
Honestly, I don't know how I'd destroy anything in my system by sofware.
Including the harddrive.
> The only thing I'm surprised by now is all the negative energy
> put forth for no real gain - against Andre's hard work. Why not
> spend time fixing other broken things instead? If everyone
> attacks every solution to every problem, then we get
> nowhere.
Well, as Andre put it, the 'fix' for the 'problem' is rather extensive
(several hundred lines added to kernel). Is this worth for a feeible
protection against selffootshooting?
Also, if I understand the patch correctly, it kills all possibilities of
for example drive firmware update without first adding support to that
to the kernel explicitly. Is this really worth it?
-- Vojtech Pavlik SuSE Labs- 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 : Sun Jul 23 2000 - 21:00:15 EST