[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 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 |