Re: [libdc] Broadcast write requests desired in the kernel interface?
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Stefan R. <st...@s5...> - 2008-10-05 20:33:56
|
On 07 June 2008 I wrote to libdc1394-devel: > Damien Douxchamps wrote: >> OK, so if eth and sbp2 are "safe" by not using bcast, then what else >> could use it besides libdc1394? dv1394? > > There is not much harm that can be done by talking to DV devices, or > AV/C devices in general. Their character device file permissions would > usually be set rather lax, e.g. writable by a video group to which > normal users belong to. > > I don't know AV/C well enough; the question is whether devices accept > broadcast write requests to the FCP_COMMAND register. If yes, a program > could for example start video streaming or things like that. The > program would then have to have write permission on at least one > arbitrary device file for a node on the same bus to use that one for > reception or transmission of a video or audio stream. > > However, I find it unlikely that any FireWire device file will get > looser permissions than a device file for an AV/C device. > > A general issue is whether devices accept broadcast write requests into > CSR architecture core registers, notably RESET_START. I should test > this with the various SBP-2 devices I got. I now subjected a few SBP-2 devices to a write request to ffff (broadcast node ID) ffff,f000,000c (reset_start CSR). HDDs based on INIC-2430, OXFW912, PL3507, TSB42AA9: OK HDDs based on OXFW911, OXUF922, OXUF924DSB, and a presumably SYMFWxxx based portable CD-RW: Become unresponsive, i.e. subsequent SCSI I/O times out and results in the SCSI device taken offline. The sbp2 driver's fetch agent reset has no effect. Remedies are power-cycling the device or just plugging the FireWire cable out and in again. So, if you have for example an IIDC device and an SBP-2 device on the same bus, and an udev script sets liberal permissions/ownership of the IIDC device's character device file, then an unprivileged user could issue a broadcast write request to reset_start through that file and it would also affect the SBP-2 device. However, the same effect can be had without broadcast write requests already today by frequently issuing bus resets. Then the sbp2 driver would be unable to do IO either because it is busy reconnecting. Hence I don't think that this particular issue with broadcast transactions should hold us back from adding the "send broadcast request" ioctl. -- Stefan Richter -=====-==--- =-=- --=-= http://arcgraph.de/sr/ |