Messages in this thread | | | Date | Sun, 20 Jul 2014 15:27:25 +0200 | From | Christoph Hellwig <> | Subject | Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO |
| |
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.
| |