On Fri, May 24, 2013 at 11:45:33AM +0200, Paolo Bonzini wrote:
> > It's not just unimplemented commands. Exposing any new command exposes
> > its borderline problems together with it.
>
> For commands that are used by Linux already, the right way to fix the
> problems is not obscuring the commands from userspace's view. You can
> hit the same problems with ioctls or even with normal operation of the
> device.
The kernel is providing an isolation layer between the userland and
the devices. It isn't obscuring. We can go through many adjectives
but it's still increasing the amount exposed surface and accelerating
expansion of cdb filter.
> And prohibiting the extension of whitelists is gonna increase the
> usage of unpriv_sgio and less-secure userspace whitelists.
>
> Anvil, meet hammer.
Delegating full device access is still a fringe use case compared to
generic block RW access. Given thta we're expecting to have an extra
separation layer albeit in userland, the overall picture doesn't seem
to favor extension of whitelists.
> > If the bulk of filtering can be solved with userland whitelisting as a
> > confined user, it should be possible to resolve peripheral problems
> > like log messages in simpler way, no? Can you please elaborate on the
> > log message problem? Who's spewing those messages?
>
> For example:
>
> if (bdev_write_same(bdev)) {
> unsigned char bdn[BDEVNAME_SIZE];
>
> if (!blkdev_issue_write_same(bdev, sector, nr_sects, gfp_mask,
> ZERO_PAGE(0)))
> return 0;
>
> bdevname(bdev, bdn);
> pr_err("%s: WRITE SAME failed. Manually zeroing.\n", bdn);
> }
>
> return __blkdev_issue_zeroout(bdev, sector, nr_sects, gfp_mask);
>
> The device exposes the ability to zero out LUN blocks, but the command is
> not whitelisted and it fails.
Which can be solved by userland filtering, right?
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
