linux-toradex.git/block/scsi_ioctl.c, branch v3.6

scsi: Silence unnecessary warnings about ioctl to partition

2012-06-15T10:52:46+00:00

Sometimes, warnings about ioctls to partition happen often enough that they
form majority of the warnings in the kernel log and users complain. In some
cases warnings are about ioctls such as SG_IO so it's not good to get rid of
the warnings completely as they can ease debugging of userspace problems
when ioctl is refused.

Since I have seen warnings from lots of commands, including some proprietary
userspace applications, I don't think disallowing the ioctls for processes
with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.

CC: Paolo Bonzini 
CC: James Bottomley 
CC: linux-scsi@vger.kernel.org
Acked-by: Paolo Bonzini 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe

block: fail SCSI passthrough ioctls on partition devices

2012-01-14T23:07:24+00:00

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds

block: add and use scsi_blk_cmd_ioctl

2012-01-14T23:07:24+00:00

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds

block: drop unnecessary blk_get/put_queue() in scsi_cmd_ioctl() and blk_get_tg()

2011-10-19T12:31:25+00:00

blk_get/put_queue() in scsi_cmd_ioctl() and throtl_get_tg() are
completely bogus.  The caller must have a reference to the queue on
entry and taking an extra reference doesn't change anything.

For scsi_cmd_ioctl(), the only effect is that it ends up checking
QUEUE_FLAG_DEAD on entry; however, this is bogus as queue can die
right after blk_get_queue().  Dead queue should be and is handled in
request issue path (it's somewhat broken now but that's a separate
problem and doesn't affect this one much).

throtl_get_tg() incorrectly assumes that q is rcu freed.  Also, it
doesn't check return value of blk_get_queue().  If the queue is
already dead, it ends up doing an extra put.

Drop them.

Signed-off-by: Tejun Heo 
Cc: Vivek Goyal 
Signed-off-by: Jens Axboe

block: take care not to overflow when calculating total iov length

2010-11-10T13:40:42+00:00

Reported-by: Dan Rosenberg 
Cc: stable@kernel.org
Signed-off-by: Jens Axboe

block/scsi_ioctl.c: quiet sparse noise

2009-11-04T08:10:33+00:00

Quiet sparse noise about symbol's not being declared.

Symbol blk_default_cmd_filter is only used locally and should be static.

The function blk_scsi_ioctl_init() is a fs_initcall and should also be
static.

Signed-off-by: H Hartley Sweeten 
Cc: James Bottomley 
Signed-off-by: Jens Axboe

block: call blk_scsi_ioctl_init()

2009-07-10T18:31:53+00:00

Currently, blk_scsi_ioctl_init() is not called since it lacks
an initcall marking. This causes the command table to be
unitialized, hence somce commands are block when they should
not have been.

This fixes a regression introduced by commit
018e0446890661504783f92388ecce7138c1566d

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Jens Axboe

block: get rid of queue-private command filter

2009-07-01T08:56:26+00:00

The initial patches to support this through sysfs export were broken
and have been if 0'ed out in any release. So lets just kill the code
and reclaim some space in struct request_queue, if anyone would later
like to fixup the sysfs bits, the git history can easily restore
the removed bits.

Signed-off-by: Jens Axboe

block: Use accessor functions for queue limits

2009-05-22T21:22:54+00:00

Convert all external users of queue limits to using wrapper functions
instead of poking the request queue variables directly.

Signed-off-by: Martin K. Petersen 
Signed-off-by: Jens Axboe

block: add rq->resid_len

2009-05-11T07:50:53+00:00

rq->data_len served two purposes - the length of data buffer on issue
and the residual count on completion.  This duality creates some
headaches.

First of all, block layer and low level drivers can't really determine
what rq->data_len contains while a request is executing.  It could be
the total request length or it coulde be anything else one of the
lower layers is using to keep track of residual count.  This
complicates things because blk_rq_bytes() and thus
[__]blk_end_request_all() relies on rq->data_len for PC commands.
Drivers which want to report residual count should first cache the
total request length, update rq->data_len and then complete the
request with the cached data length.

Secondly, it makes requests default to reporting full residual count,
ie. reporting that no data transfer occurred.  The residual count is
an exception not the norm; however, the driver should clear
rq->data_len to zero to signify the normal cases while leaving it
alone means no data transfer occurred at all.  This reverse default
behavior complicates code unnecessarily and renders block PC on some
drivers (ide-tape/floppy) unuseable.

This patch adds rq->resid_len which is used only for residual count.

While at it, remove now unnecessasry blk_rq_bytes() caching in
ide_pc_intr() as rq->data_len is not changed anymore.

Boaz	: spotted missing conversion in osd
Sergei	: spotted too early conversion to blk_rq_bytes() in ide-tape

[ Impact: cleanup residual count handling, report 0 resid by default ]

Signed-off-by: Tejun Heo 
Cc: James Bottomley 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Borislav Petkov 
Cc: Sergei Shtylyov 
Cc: Mike Miller 
Cc: Eric Moore 
Cc: Alan Stern 
Cc: FUJITA Tomonori 
Cc: Doug Gilbert 
Cc: Mike Miller 
Cc: Eric Moore 
Cc: Darrick J. Wong 
Cc: Pete Zaitcev 
Cc: Boaz Harrosh 
Signed-off-by: Jens Axboe