Hotplug, 1394, and security

Here are my thoughts on how to solve the current problems with 1394 hotplug and raw1394 security. I am starting work on an implementation but am posting this now in case I'm completely on the wrong track or something.

Currently, /dev/raw1394 offers full access to the entire 1394 bus from userland. User programs (such as audio and video software) use this device to access other nodes on the bus, and must have full access to it. This is clearly bad from a security point of view: there's nothing stopping a malicious program from accessing other nodes, such as sbp2 disks, etc.

Also, we need to decide how best to handle new devices, such as the 1394 audio devices being supported by the FreeBob project. The prototype implementation simply runs as a daemon that waits for bus resets, probes devices, and provides information on AV/C audio devices to the streaming driver. I'd like to eliminate the need for the daemon by having hotplug do some of this work, and the streaming driver the rest.

Here's what I propose:

- Create /dev/bus/ieee1394, which will look approximately like:
0/ - representing the first ieee1394 port
ffc0 - node 0 on first port
ffc1 - node 1
iso - isochronous traffic
arm - address range mappings
1/ - second port
ffc0 - ...
iso
arm

- Read and parse complete ConfigROMs from the kernel and make this information available via sysfs. Thoughts on how best to represent
this would be appreciated.

- Send hotplug events when new devices are added, devices are removed, and when the ConfigROM of an existing device changes.

- Hotplug will use the information in sysfs to manage /dev/bus/1394 nodes.

- The FreeBob streaming driver finds AV/C devices using the sysfs information and performs AV/C discovery/enumeration to see if they are
audio devices.

- /dev/raw1394 will continue to exist and provide complete access to all buses, but will normally be accessible to root only.

- Enhance libraw1394 (which all userland programs that access the bus ought to be using) to use the /dev/bus/ieee1394 devices when
/dev/raw1394 is inaccessible or unavailable.

Open questions:

- Should the kernel be dealing with ConfigROMs? I think so, but an alternative is to have a utility linked against libraw1394 that
hotplug uses to read and manage ConfigROM information, instead of using sysfs.

- Should the node entries in /dev/bus/ieee1394 allow complete access to that node or should we attempt to filter potentially harmful
activities like writes to core CSR registers (RESET_START, timeouts, etc.)

- Should we also do AV/C discovery and enumeration? This is necessary to distinguish between AV/C audio devices and video cameras, but I
don't think these need different permissions.

- This does push a lot of the work currently done by the FreeBob daemon down into the streaming driver (presumably via libfreebobctl.) Would
it be better to have hotplug launch something to do this work?

All comments welcome :)