That is not my problem to solve.
That is the problem of the sub-system to address.
The liablity issue of allow a default setting have the ablitiy to damage a
customer's hardware or business is a legal issue that I do not want to
have to defend in a Court of Law.........
Must I walk the whole idea from beginning to end?
We all know the Emperor Penguin is NUDE, because the source code is public.
That which you can not see, you can not be sued for .........
Later!
On Sun, 23 Jul 2000, Andreas Bombe wrote:
> On Fri, Jul 21, 2000 at 11:43:15AM -0700, Andre Hedrick wrote:
> >
> > If you try to pass raw taskfile command to the drive and you have no clue.
> > The hardware will BUCK 99% of the time.
> >
> > Using the kernel IOCTL, it BUCKS 5% of the time and the damage is done.
> > Baically, you want me to continue helping you destroy your hardware.
> > I will not be a part of that!
> >
> > Do you allow USB to send unrestricted commands that will damage the
> > hardware?
>
> Let's have a different example: IEEE 1394, aka FireWire. The subsystem
> provides the raw1394 module, which does allow to send raw (mostly, see
> below) packets to any node on the bus. This may include disks, which
> may have dangerous commands.
>
> A short overview of 1394. This standard is an implementation of IEEE
> 1212 (CSR architecture), and as such it implements only (ignoring
> isochronous transmissions, which do only data and no commands anyway)
> three basic commands: read, write, lock (lock does some indivisable
> operations). The whole architecture is memory based, commands are not
> implemented by special transaction codes but by memory registers with
> specified side effects on read/lock/write.
>
> raw1394 does not actually allow to create real raw packets, it creates
> the packets itself from requests like "write address x on node y with
> data z" (necessary, since the kernel has to handle the responses).
>
> Every node has an address space of 256 TB (48 Bit address).
>
> We can't filter by command here, since we only see addresses. How would
> you filter *that*? Addresses may be specified by standards or be vendor
> extensions. Which addresses do we allow, which do we reject? Should we
> download and parse the configuration ROM of the target node to find out
> what kind of device it is in the first place (i.e. this address is only
> to be allowed on digital video devices)? Since address ranges exist
> that serve as reception space for complete commands, should we examine
> the data to be sent if the target address matches this?
>
> How can the kernel know what is right and what is wrong? How is this
> situation different from IDE or SCSI? Should the raw1394 driver be
> wiped entirely and complete kernel drivers required for every little
> digital camera device?
>
>
> This reminds me that I should put a CAP_SYS_RAWIO check into raw1394.
>
> --
> Andreas E. Bombe <andreas.bombe@munich.netsurf.de> DSA key 0x04880A44
> http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/
>
Andre Hedrick
The Linux ATA/IDE guy
-
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