On Mon, 24 Jul 2000, Khimenko Victor wrote:
> In <Pine.LNX.4.21.0007240239040.12536-100000@tricky> Bartlomiej Zolnierkiewicz (dake@staszic.waw.pl) wrote:
> > On Mon, 24 Jul 2000, Taso Hatzi wrote:
> >> Is this a problem for all brands of IDE drive?
> >> If not, then which brands protect themselves?
>
> > What about doing some tests, any volunteers :-)
>
> > Or let's write some diagnostic tool:
> > "
> > [root@grill.now]# ./d2b
> > brick-test: /dev/hda Model X FwRev Y: is vulnerable... :-)
> > brick-test: /dev/hdc Model A FvRev B: is vulnerable... :-)
> > ...
> > "
>
> > [forgive me my stupidity...]
>
> I forgive you. It DOES NOT work this way. I'll try to explain what happened
(...)
Great. I understand very well how the things work, anyway nice explanation.
> As you can see this disktobrick not exist yet at all. It's pretty obvious
Yet. What if somebody writes brick-test with a HUGE database of HDDs?
Right now it's rather impossible for average mortal (not for goverment
agencies etc.) due limited information.
> that disktobrick CAN be created (for some HDDs at least) but for each and
> every HDD flavour you'll need you own version (see above). What's more:
> there are exist HDD hurtable with CORRECT ATAPI commands. So it really
So... brick-test may include "generic tests" also...
> DOES NOT look like we can get significant gains with Andre's plates in place.
The main source of the whole threat (in *big* simplification) is that
Andre thinks "Linux IDE driver isn't compliant with a ATA-ATAPI standard,
it is dangerous in many ways and should be fixed". His opponets think "An
attacker can destroy your hdd even if Linux IDE driver is compliant with a
standard."
I fully agree that it's hdd manufacturers job to make hardware not
vulnerable and it can be done (jumper/crypto) and that they try to move
responsibility to kernel/user. It is bad. When kernel IDE/ATA _driver_
is standard compliant they cannot say "It's Linux kernel fault" when
somebody fries your hdd. But can't they still say that because kernel
will never be ATA standard compliant, because it cannot prevent (like any
other OS?) sending IO stuff by privileged user (except CAP_SYS_RAWIO
case) ?
Including CAP_SYS_RAWIO is obviously a right thing but Andre's patch
also has some value (at least these few chunks not related with commands
filtering). BTW I'm sure if Andre had presented his patch as IDE cleanup
it would have been accepted ;-) (only joking don't take it seriously)
nothing new from me again...
-- Bartlomiej Zolnierkiewicz <bkz@linux-ide.org>- 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:16 EST