In <397A7CDB.9E5AE76E@mcn.net> TimO (hairballmt@mcn.net) wrote:
Looks like you STILL do not understood. RAW IO is ENOUGH to write disk2brick.
RAW IS is NOT enough to do firmware upgrades in sane way. So Andre's patch
gives you VERY little in sense of security while still removes potentially
desired functionality from kernel. BTW it's VERY hard to make brick out of
your disk while developing non-related program and if you are developing
firmware upgrade program you should disable all such checks anyway. So this
patch is useless as security tool and almost useless and safety tool (you can
destroy enough drives out there while useng only "safe" commands allowed by
Andre's patch).
> I am really starting to empathize with Andre here. He's talking safety,
> you guys preach security; he says via the kernel API, you say there is
> still RAW_IO. The problem is that these commands are VENDOR SPECIFIC,
> outside the ATA-ATAPI specs and undocumented/not publicly available. As
> such you don't KNOW if you're sending disktobrick to the drive or not.
> What Andre wants to do is limit the kernel API to the ATA-ATAPI specs so
> this cannot happen in normal/development use. If you're worried about
> losing the ability to FLASH your firmware, just use an SUID root userland
> program which writes via RAW-IO. At least in this way the program will
> know what these commands are and use them in the proper context; not frying
> your hardware when testing a new driver for robustness ie. properly
> returning -ENOTATA instead.
> just my $.02 cents worth - seems everybody else got there's. :)
-
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:20 EST