2.6.8 uses SCSI for CD recording?
Posted Aug 19, 2004 11:02 UTC (Thu) by rjw
In reply to: 2.6.8 uses SCSI for CD recording?
Parent article: 2.6.8 and CD recording
Most hardware storage devices (Firewire, USB, SATA, PATA) do in fact work in terms of scsi commands (or very minor variations) internally.
We have a SCSI layer. We use it for these SCSI based devices whether they use a SCSI cable standard or not.
As SCSI is so universal, it is becoming pointless to name device nodes like that. So eg IDE cdwriters can just be opened as /dev/hdc or whatever, and scsi commands issued. This is AFAIK possible in 2.6.
I'm sure patches that cleared up device naming in other encapuslated SCSI situations would be accepted ( eg SBP2, libata).
The problem here is that the SCSI standards (and all these encapsulated-SCSI standards) have not really fully encompassed the full range of what the devices are capable of. So its very hard to tell how much damage any particular command can do, as it might do different things
Basically, its a big old standards mess, and it is up to the vendors to sort out - if they can be bothered.
For existing drives, this becomes very similar to the X security question. Graphics cards often have total DMA freedom. So we have a few choices:
a) large parts of cdrecord in the kernel - eek.
b) trusted demon / suid binary - eek
c) command checking in the kernel for dodgy commands.
c) is what they are doing here. b) is what X does currently, but moving to c) (with quite some pain) . But if the commands are totally arbitrary, maybe userspace setup using a trusted udev/hotplug/hal callout (which informs the kernel of an allowed set of commands) would be the best way of dealing with it. Any extra userspace is always ultra painful to get in the distros though.
to post comments)