Why? What if I really want to update the firmware is say my CD-RW, and
it doesn't use any of the ATA-spec commands for that? Should it fail?
I think filtering bad requests is OK - validating stuff like
permissions, concurrent access, pointers, whatever, but the kernel
shouldn't have hardcoded tables of commands that are allowed.
The "right solution", if we really need command filtering is an ioctl
and an utility that can fill a 'filter table', which says which commands
are ok for whom and which are not. Like 'INQUIRY can be used by anyone',
'no, I won't send anything related to CPRM to the drive'. Easy to
implement, no huge case statements needed.
> If we wanted to be ultra-super-paranoid, drop the ioctl and taskfile
> parser, and implement the taskfile checks via SMM mode callbacks from
> activity on the IDE ports ;-) That way we know the NSA is not doing
> something sneaky, as well as supporting unlimited SMP bit-banging from
> userland. Can you say ug and non-portable even to a lot of ia32
> platforms. :)
>
> So, the implementation may need improvement, but we do (a) want the
> taskfile ioctl [and one for scsi too], and (b) want to implement some
> amount of mininal sanity checks on the requests.
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/