On Thu, Dec 01, 2016 at 02:04:56AM -0800, Christoph Hellwig wrote: > On Wed, Nov 30, 2016 at 07:50:07PM -0500, Keith Busch wrote: > > I think we should get rid of the "majmin" stuff > > Absolutely agreed. > > > > > and directly use > > block_device. Then if we add the security send/receive operations to the > > block_device_operations, that will simplify chaining the security request > > to the driver without needing to thread the driver's requested callback > > and data the way you have to here since all the necessary information > > is encapsulated in the block_device. > > Maybe. I need to look at the TCG spec again (oh my good, what a fucking > mess), but if I remember the context if it is the whole nvme controller > and not just a namespace, so a block_device might be the wrong context. > Then again we can always go from the block_device to the controller > fairly easily. So instead of adding the security operation to the > block_device_operations which we don't really need for now maybe we > should add a security_conext to the block device so that we can avoid > all the lookup code? I spent some time this morning reading through the numerous specs/documents, with a lot of coffee. Specifically in: https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_SWG_SIIS_Version_1_02_Revision_1_00_20111230.pdf 5.5.2 Namespace A target that has multiple Namespaces MAY have multiple TPers. Each TPer SHALL be associated with a different Namespace. Every Namespace on a device is not required to have a TPer, but Namespaces that support the TCG Core specification commands and functionality SHALL have a TPer. A TPer SHALL only be associated with exactly one Namespace. A Namespace MAY have no TPer. >From reading that it seems we will probably have to keep it at the block layer, since its possible to have a valid "Locking range 1" on n1 and a "Locking range 1" on n2. [snip] -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
