|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH] xen-block: introduces extra request to pass-through SCSI commands
On 03/01/2016 12:29 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [RFC PATCH] xen-block: introduces extra request to
> pass-through SCSI commands"):
>> [stuff suggesting use of PVSCSI instead]
>
> For the avoidance of doubt:
>
> 1. Thanks very much for bringing this proposal to us at the concept
> stage. It is much easier to discuss these matters in a constructive
> way before a lot of effort has been put into an implementation.
>
> 2. I should explain the downsides which I see in your proposal:
>
> - Your suggestion has bad security properties: previously, the PV
> block protocol would present only a very simple and narrow
> interface. Your SCSI CDB passthrough proposal means that guests
> would be able to activate features in SCSI targets which would be
> unexpected and unintended by the host administrator. Such features
> would perhaps even be unknown to the host administrator.
>
> This could be mitigated by making this feature configurable, of
> course, defaulting to off, along with clear documentation. But it's
> not a desirable property.
>
> - For similar reasons it will often be difficult to use such a feature
> safely. Guest software in particular might expect that it can
> safely use whatever features it can see, and do all sorts of
> exciting things.
>
> - It involves duplicating multiplexing logic which already exists in
> PVSCSI.
>
One thing I'm still not sure about PVSCSI is do we have the same security issue
since LIO can interface to any block device.
E.g when using a partition /dev/sda1 as the PVSCSI-backend, but the
PVSCSI-frontend may still send SCSI operates on LUN bases (the whole disk).
P.S. Thanks to all of you, it helps a lot!
--
Regards,
-Bob
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |