linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, pmatouse@redhat.com,
	"James E.J. Bottomley" <JBottomley@parallels.com>,
	linux-scsi@kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 06/13] sg_io: whitelist a few more commands for multimedia devices
Date: Fri, 25 Jan 2013 23:32:42 +0100	[thread overview]
Message-ID: <5103080A.4090803@redhat.com> (raw)
In-Reply-To: <20130125190154.GM3081@htj.dyndns.org>

Il 25/01/2013 20:01, Tejun Heo ha scritto:
> Some did that at least in ATA.  It was mapping some command to
> firmware write.  Given how many USB devices implement SCSI these days,
> I wouldn't be too firm with "that doesn't happen".  How can such
> all-covering statement be asserted?

Of course it cannot be asserted.  In the same way as it cannot be
asserted that "no program will try to use a command".  It is just as
unsafe to keep a command in, as it is unsafe to keep a command out.

All you can do is use common sense, which says that if a command has
been in a standard, someone has likely used it.  Of course someone
_might_ have misused it too, but how likely is that?

To try and give an answer, I grepped the "unusual" drivers in
drivers/usb/storage.  All of them seem to use non-standard packets (i.e.
basically are not SCSI) for their strange stuff, except two:
initializers.c has one function that sends SCSI command 0xEC,
realtek_cr.c uses 0xF0, both vendor specific.  So USB firmware writers,
despite being known for tweaking SCSI standards in many ways, seem to be
sensible in this respect.

What about the likelihood that someone _used_ particular commands?  For
example, I know that REZERO UNIT (which has been obsolete for several
releases of the standard) is used in the wild because a patch to support
it was submitted to QEMU not long ago.  Some commands are indeed no-ops
or almost no-ops, or just too obscure to care (such as the two MMC
commands), so I wouldn't spend too much time to discuss them, but it
should be unnecessary if we stick to a principle that is logical and
generally applicable.  "Someone may have misused it" is not one.

>>> So, there are actual costs coming from exposing them, which is fine if
>>> the benefit can offset them enough, but what would be the benefit of
>>> exposing commands which aren't being used?
>>
>> If it is not used, nobody will use it and nothing will break.
> 
> I have to say that's an overly optimistic view of the world.  There
> are even devices puking on receiving SCSI commands in a slightly
> different sequence than windows sends them out and devices which lock
> up if you send them enough TURs.

If it is not used, nobody will use it and setting the bit is effectively
useless (but harmless too).

>>> , so that doesn't seem like
>>> that much of winning to me.  Discovering use cases is actually much
>>> easier than finding broken devices for some obscure commands.
>>
>> Not if many of your uses are proprietary (Windows, AIX on PPC, z/OS on
>> s390, Oracle, SAP, you name it).
> 
> You would get -EPERM/ACCES whatnot from base OS and you would know the
> command in use, no?

Yes, but I would like to avoid many iterations.  I don't have access
myself to all that software except Windows.

Paolo

  reply	other threads:[~2013-01-25 22:32 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 15:00 [PATCH 00/13] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542) Paolo Bonzini
2013-01-24 15:00 ` [PATCH 01/13] sg_io: pass request_queue to blk_verify_command Paolo Bonzini
2013-01-24 22:34   ` Tejun Heo
2013-01-24 15:00 ` [PATCH 02/13] sg_io: reorganize list of allowed commands Paolo Bonzini
2013-01-24 22:42   ` Tejun Heo
2013-01-24 22:49     ` Tejun Heo
2013-01-24 22:58       ` Tejun Heo
2013-01-25 10:01         ` Paolo Bonzini
2013-01-25 17:13           ` Tejun Heo
2013-01-25 17:26             ` Paolo Bonzini
2013-01-24 15:00 ` [PATCH 03/13] sg_io: use different default filters for each device class Paolo Bonzini
2013-01-24 15:00 ` [PATCH 04/13] sg_io: resolve conflicts between commands assigned to multiple classes (CVE-2012-4542) Paolo Bonzini
2013-01-24 15:00 ` [PATCH 05/13] sg_io: whitelist a few more commands for rare & obsolete device types Paolo Bonzini
2013-01-24 15:00 ` [PATCH 06/13] sg_io: whitelist a few more commands for multimedia devices Paolo Bonzini
2013-01-24 22:55   ` Tejun Heo
2013-01-25  9:26     ` Paolo Bonzini
2013-01-25 17:04       ` Tejun Heo
2013-01-25 17:16         ` Paolo Bonzini
2013-01-25 17:28           ` Tejun Heo
2013-01-25 17:57             ` Paolo Bonzini
2013-01-25 18:13               ` Tejun Heo
2013-01-25 18:47                 ` Paolo Bonzini
2013-01-25 19:01                   ` Tejun Heo
2013-01-25 22:32                     ` Paolo Bonzini [this message]
2013-01-25 22:41                       ` Tejun Heo
2013-01-25 23:32                         ` Paolo Bonzini
2013-01-25 23:47                           ` Tejun Heo
2013-01-26 10:18                             ` Paolo Bonzini
2013-01-24 15:00 ` [PATCH 07/13] sg_io: whitelist a few more commands for media changers Paolo Bonzini
2013-01-24 15:00 ` [PATCH 08/13] sg_io: whitelist a few more commands for tapes Paolo Bonzini
2013-01-24 15:00 ` [PATCH 09/13] sg_io: whitelist a few more commands for disks Paolo Bonzini
2013-01-24 15:00 ` [PATCH 10/13] sg_io: whitelist a few obsolete commands Paolo Bonzini
2013-01-24 15:00 ` [PATCH 11/13] sg_io: add list of commands that were in the consulted list but are disabled Paolo Bonzini
2013-01-24 15:00 ` [PATCH 12/13] sg_io: remove remnants of sysfs SG_IO filters Paolo Bonzini
2013-01-24 15:00 ` [PATCH 13/13] sg_io: introduce unpriv_sgio queue flag Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5103080A.4090803@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=JBottomley@parallels.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@kernel.org \
    --cc=pmatouse@redhat.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).