> > > > > > An FMR can be used to advertise a target buffer that is being read into > > as a single logical buffer. Using physical memory would require > > > > a) exporting the physical page list of where your buffers were (making > > the buffer advertisement larger and more complex) > > > > b) Trusting whoever is on the other end of the connection with access > > to your entire physical memory. > > I assume that iSER (like SRP) supports scatter gather in I/O requests, so a) > shouldn't matter - that is, I expect that the storage subsystem hands the > iSER driver a list of physical addresses and a SCSI-like command. Copying > the page list is far simpler than getting a virtual address. > > I see no issue with trusting I/O controllers on the fabric. They are no > more a threat than local I/O controllers. This addresses issue b). >
I must have missed something in the spec. Where is the cryptographic header that guarantees that you are indeed connected to another I/O controller and not somebody just claiming to be an iSER device? Isn't that akin to assuming that the 'root' user on that other system is another sysadmin so I can trust them? Generally I assume the entity on the other end of the wire is under the complete control of an attacker. So if I only want to expose a single 1MB buffer consisting of 256 scattered pages I should be able to do so, because I have designed my daemon so that it will not be damaged no matter what the remote peer puts in that 1MB. They can damage their content, but that's all. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
