Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))

From: "Theodore Ts'o" <tytso@mit.edu>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Tejun Heo <tj@kernel.org>,
	"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 11:03:35 -0400	[thread overview]
Message-ID: <20130522150335.GC2777@thunk.org> (raw)
In-Reply-To: <519CD234.40608@redhat.com>

Paolo,

I'll probably regret butting my head into this, but it might be
helpful if you talk about your particular use case which is driving
your desire to make these changes.  For example, what do you think the
SG_IO whitelist _should_ be used, and why should it be made more
general?  What's the use case that is being impaired by the current
state of how sg_io whitelists are being handled?

Secondly, when you are trying to get a security vulnerability fixed,
it's helpful if you give the precise nature of the problem, and what
the an attacker can do with it.  I think you are worried that if an
attacker has read-only access, they can still send the UNMAP command
which may (since it is advisory) result in a block no longer
containing valid data, such that a read will return zero's or some
other undefined garbage.   Yes?

Now consider that if this is a high-priority fix, it's important to
make the patch as small as possible, since distributions (like your
employer) may want to backport the patch to older kernels.  And
distribution release engineers will appreciate things if the patch is
as small as possible, making the _minimum_ necessary changes to fix
said security exposure.  Generally, a series of 14 patches is __not__
the minimum necessary patch.

Finally, please consider that your attitude is not going to win
friends and influence people.  I don't know if the capability to work
well with upstream developers (people which ***other*** Red Hat
engineers have had no problems work with, and which I can attest,
through personal experience, are very reasonable engineers who are
easy to work with), is something which is a part of your performance
review process.  But if it isn't, it probably should be, since the
ability to listen to review feedback is going to be important for your
long term career prospects, no matter whether it is with the Linux
kernel, some other open source project, or even a proprietary softare
project.

Regards,

					- Ted