linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
Date: Wed, 22 May 2013 17:00:52 +0200	[thread overview]
Message-ID: <519CDDA4.2050100@redhat.com> (raw)
In-Reply-To: <20130522143019.GA18541@mtj.dyndns.org>

Il 22/05/2013 16:30, Tejun Heo ha scritto:
> * Separate fixes from additions.  Transform existing code so that the
>   visible behavior doesn't change but the required fix can be
>   implemented on top.  Explicitly note what's going on in the commit
>   messages.

Been there, done that.  Have you read the commit messages *at all*?

Patch 2: "Right now, there is still just one bitmap and the mask is
ignored, so there is no semantic change yet".

Patch 3: "This patch already introduces some semantic change, albeit
very limited; [...] a few commands are now forbidden for devices of type
other than TYPE_ROM, where they are reserved or vendor-specific".

> * Fix the frigging CVE bug that you've been waving around and do
>   *just* that.

Perhaps you've missed that this is v2, not v27.  Tell me a place in the
original review where you've told me to split the series.

> * Add the frigging "count me out" feature that you want for your use
>   case.  It isn't controversial and is what you need and the
>   maintainer can apply to the point where [s]he thinks acceptable.

Sure.  Except I had sent it six months ago, and it lied unreviewed
despite your acks for two months.  It is in the archives waiting to be
picked up.

> * If for whatever reason you have to add more command codes to the
>   exception table, do them with explicit justifications.  How the hell
>   "the vast majority of the commands are added because Linux itself is
>   using them" a proper justification?   How are they used for what
>   reason and why is adding them beneficial?

For example, WRITE SAME is used to discard blocks.  If a Linux guest
wants to discard blocks, it may send WRITE SAME.  If a disk advertises
support for WRITE SAME, it is not nice if WRITE SAME then fails because
of a stupid whitelist that was designed for CD-ROMs.

And another disk instead works because it uses UNMAP instead of WRITE
SAME.  It's a support nightmare, perhaps the cause is obvious to me by
the time it reaches me, but that takes time---which is wasted time for
everyone involved.

>   How many times have I
>   asked you to give at least some useful use cases?  And WTF is "vast
>   majority", what about others then?

The others are not in v2, or are sent by udev, or were added to the
standard for a reason and applications are using them (e.g. COMPARE AND
WRITE).

>   Why do you need this at all if
>   you have the "count me out" knob in the first place?

Because the "count me out" knob needs privileges.  It opens up way, way
more than what these patches do.

And the frigging patch to make the whole whitelisting
userspace-configurable with finer-grain (but still with appropriate
capabilities) was nacked.  By you, for God's sake.

http://permalink.gmane.org/gmane.linux.kernel/1378071

>   You first
>   built that command list by scanning the spec and just adding the
>   commands that seemed "right" to you.

And then in v2 I stated that I removed some disk commands because of
discussion with you.  But of course you don't know, because you've not
read the damn commit messages.

>   I have near-zero confidence in
>   your perception of the relationship between the specs and actual
>   world.

Thankyouverymuch.  Perhaps you should have read the commit messages (oh
sorry, have I said it already?) and seen that it's not about commands
that seemed "right":

   Only commands that affect the medium are added.
   Commands that affect other state of the LUN are all privileged, with
   the sole exception of START STOP UNIT (which has always been
   allowed for all file descriptors.  I do not really agree with that
   and it's probably an artifact of when /dev/cdrom had
   r--r--r-- permissions, but I'm not trying to change that.

> So, stop quoting and repeating yourself.  You're overdoing yourself on
> that department already.  Try to listen and understand for a change.

Guy, calm down.  We're two.

Paolo


  reply	other threads:[~2013-05-22 15:01 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06 15:15 [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542) Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 01/14] sg_io: pass request_queue to blk_verify_command Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 02/14] sg_io: reorganize list of allowed commands Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 03/14] sg_io: use different default filters for each device class Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 04/14] sg_io: resolve conflicts between commands assigned to multiple classes (CVE-2012-4542) Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 05/14] sg_io: whitelist a few more commands for rare & obsolete device types Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 06/14] sg_io: whitelist another command for multimedia devices Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 07/14] sg_io: whitelist a few more commands for media changers Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 08/14] sg_io: whitelist a few more commands for tapes Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 09/14] sg_io: whitelist a few more commands for disks Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 10/14] sg_io: whitelist a few obsolete commands Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 11/14] sg_io: mark blk_set_cmd_filter_defaults as __init Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 12/14] sg_io: remove remnants of sysfs SG_IO filters Paolo Bonzini
2013-02-06 15:16 ` [PATCH v2 13/14] sg_io: introduce unpriv_sgio queue flag Paolo Bonzini
2013-02-06 15:16 ` [PATCH v2 14/14] sg_io: use unpriv_sgio to disable whitelisting for scanners Paolo Bonzini
2013-02-13  8:32 ` [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542) Paolo Bonzini
2013-02-13 15:35   ` Douglas Gilbert
2013-02-13 15:48     ` Paolo Bonzini
2013-02-20 16:12 ` Paolo Bonzini
2013-03-22 22:30   ` PING^2 " Paolo Bonzini
2013-04-04 18:18     ` PING^3 " Paolo Bonzini
2013-04-17 12:26       ` PING^4 aka The Jon Corbet Effect " Paolo Bonzini
2013-04-27 13:31         ` PING^5 aka New ways to attract attentions " Paolo Bonzini
2013-05-06 20:43   ` PING^6 " Paolo Bonzini
2013-05-22  6:35 ` PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542)) Paolo Bonzini
2013-05-22  9:32   ` Tejun Heo
2013-05-22  9:53     ` Paolo Bonzini
2013-05-22 10:02       ` Tejun Heo
2013-05-22 10:23         ` Paolo Bonzini
2013-05-22 12:07           ` James Bottomley
2013-05-22 14:07             ` Paolo Bonzini
2013-05-22 16:31               ` Paolo Bonzini
2013-05-22 13:41           ` Tejun Heo
2013-05-22 14:12             ` Paolo Bonzini
2013-05-22 14:30               ` Tejun Heo
2013-05-22 15:00                 ` Paolo Bonzini [this message]
2013-05-22 19:30                   ` Tejun Heo
2013-05-22 21:18                     ` Paolo Bonzini
2013-05-22 22:17                       ` Tejun Heo
2013-05-23  0:54                         ` Tejun Heo
2013-05-23  7:45                         ` Paolo Bonzini
2013-05-23  9:02                           ` Tejun Heo
2013-05-23  9:47                             ` Paolo Bonzini
2013-05-24  1:44                               ` Tejun Heo
2013-05-24  7:13                                 ` Paolo Bonzini
2013-05-24  8:02                                   ` Tejun Heo
2013-05-24  8:31                                     ` Paolo Bonzini
2013-05-24  9:07                                       ` Tejun Heo
2013-05-24  9:45                                         ` Paolo Bonzini
2013-05-24 22:20                                           ` Tejun Heo
2013-05-25  4:35                                     ` James Bottomley
2013-05-25  5:27                                       ` Christoph Hellwig
2013-05-25  7:05                                         ` Paolo Bonzini
2013-05-25  7:11                                           ` Christoph Hellwig
2013-05-25  7:21                                             ` Paolo Bonzini
2013-06-21 11:57                                           ` Christoph Hellwig
2013-05-25  8:37                                       ` Tejun Heo
2013-05-25 11:14                                         ` Paolo Bonzini
2013-05-25 12:48                                           ` Tejun Heo
2013-05-25 12:56                                             ` Paolo Bonzini
2013-05-22 15:03               ` Theodore Ts'o
2013-05-22 15:53                 ` Paolo Bonzini
2013-05-22 16:32                   ` Martin K. Petersen
2013-05-22 17:00                     ` Paolo Bonzini
2013-05-22 18:11                       ` Theodore Ts'o
2013-05-22 19:37                         ` Paolo Bonzini
2013-05-22 20:19                           ` Theodore Ts'o
2013-05-22 20:36                             ` Paolo Bonzini
2013-05-25  3:54                     ` Vladislav Bolkhovitin
2013-05-28 20:25                       ` Martin K. Petersen
2013-05-29  6:12                         ` Vladislav Bolkhovitin
2013-05-22 20:39                   ` Tejun Heo
2013-05-22 21:12                     ` 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=519CDDA4.2050100@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=JBottomley@parallels.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --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).