On Sun, Jul 20, 2014 at 02:47:49PM +0300, Boaz Harrosh wrote: > > So two things here: > - hdr->cmd_len is char so can be MAX of 255. I understand that 4 bytes alignment is a SCSI > thing so you found no point of checking any max size? I don't see any point to force the aligmnet - the devices need to reject garbage commands, and if for some reason we'd see future commands that are > 252 and < 255 we are prepared to handle them. > - Why the zero alloc, if you are going to paste over it the exact same length. Now if like in scsi > you need 4 bytes alignment and zero padding yes, but here you do not do this (and probably shouldn't). > Hence why zero-alloc? No good reason except that's what sg and bsg do. > - Looking at sg.h where hdr->cmd_len is defined it stills has a comment of <= 16 you might want to > remove the comment by now. The sg changes to support > 16 byte CDs remove the comment, take a look at my core-for-3.17 tree which has them applied. > Inside here: blk_fill_sghdr_rq() calls blk_verify_command() which does: > (Below cmd[] is the buffer copied from user) > > /* Anybody who can open the device can do a read-safe command */ > if (test_bit(cmd[0], filter->read_ok)) > return 0; > > /* Write-safe commands require a writable open */ > if (test_bit(cmd[0], filter->write_ok) && has_write_perm) > return 0; > > Now I am not sure what type "Commands" you guys intend for these large commands > but if they are say SCSI-VARLEN this test will not work. Also a user might fool > the system with pretending to be "read" a device modifying command. > > I would pass len to this test function and only permit these above if command is > <= 16. Any "special" large command is root only. Honestly that whole filter crap should never have been merged to start with, you'll just need proper CAP_SYS_RAWIO for variable length commands. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
