Date:	Fri, 24 May 2013 20:54:34 -0700
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
CC:	Paolo Bonzini <pbonzini@...hat.com>, Theodore Ts'o <tytso@....edu>,
	Tejun Heo <tj@...nel.org>,
	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization
 of the SG_IO command whitelist (CVE-2012-4542))

Martin K. Petersen, on 05/22/2013 09:32 AM wrote:
> Paolo> First of all, I'll note that SG_IO and block-device-specific
> Paolo> ioctls both have their place.  My usecase for SG_IO is
> Paolo> virtualization, where I need to pass information from the LUN to
> Paolo> the virtual machine with as much fidelity as possible if I choose
> Paolo> to virtualize at the SCSI level.  
> 
> Now there's your problem! Several people told you way back that the SCSI
> virt approach was a really poor choice. The SG_IO permissions problem is
> a classic "Doctor, it hurts when I do this".
> 
> The kernel's fundamental task is to provide abstraction between
> applications and intricacies of hardware. The right way to solve the
> problem would have been to provide a better device abstraction built on
> top of the block/SCSI infrastructure we already have in place. If you
> need more fidelity, add fidelity to the block layer instead of punching
> a giant hole through it.
> 
> I seem to recall that reservations were part of your motivation for
> going the SCSI route in the first place. A better approach would have
> been to create a generic reservations mechanism that could be exposed to
> the guest. And then let the baremetal kernel worry about the appropriate
> way to communicate with the physical hardware. Just like we've done with
> reads and writes, discard, write same, etc.

Well, any abstraction is good only if it isn't artificial, so solving more problems
than creating.

Reality is that de facto in the industry _SCSI_ is the abstraction for block/direct
access to data. Look around. How many of systems around you after all layers end up to
SCSI commands in their storage devices?

Linux block layer is purely artificial creature slowly reinventing wheel creating more
problems, than solving. It enforces approach, where often "impossible" means
"impossible in this interface". For instance, how about copy offload? How about
reservations? How about atomic writes? Look at history of barriers and compare then
with what can be done in SCSI. It's still worse, because doesn't allow usage of all
devices capabilities. Why was it needed to create special blk integrity interface with
the only end user - SCSI? Artificial task created - then well solved. Etc, etc.

The block layer keeps repeating SCSI. So, maybe, after all, it's better to acknowledge
that direct usage of SCSI without any intermediate layers and translations is more
productive? And for those minors not using SCSI internally, translate from SCSI to
their internal commands? Creating and filling CDB fields for most cases isn't anyhow
harder, than creating and feeling bio fields.

So, I appreciate work Paolo is doing in this direction. At least, the right thing will
be on the virtualization level.

I do understand that with all existing baggage replacing block layer by SCSI isn't
practical and not proposing it, but let's at least acknowledge limitations of the
academic block abstraction. Let's don't make those limitations global walls. Many
things better to do using direct SCSI, hence let's do the better way.

Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists