On Thu, Dec 01, 2016 at 01:22:39PM -0500, Keith Busch wrote: > On Thu, Dec 01, 2016 at 10:53:43AM -0700, Scott Bauer wrote: > > > 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. > > Thanks for tracking that down! Specifically for NVMe, security > send/recieve requires NSID, so it is a little more difficult to get to > that if we're not using the abstracton that contains the namespace. So turns out that version is old and it has since changed: https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_SWG_SIIS_Version_1_05_Revision_1_00.pdf (section 5.5) So in this document Cristoph is right. There is a single TPER for the entire device. For devices with multiple namespaces, there will be a single global locking range. That single locking range covers the entire LBA range. Other locking ranges aren't allowed. Now, for a drive with one namespace There is a global LR and it MAY be allowed to have other user locking ranges as well. Now, with this in mind, it sort of makes sense to move this from block/ back into lib/ and interface with the character dev. Instead of passing around block_devices, we can pass around struct file *'s. Does anyone have and qualms/comments/anecdotes before I move everything around? -- 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
