lkml.org 
[lkml]   [2013]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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


    \
     
     \ /
      Last update: 2013-05-25 06:41    [W:3.795 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site