From mboxrd@z Thu Jan  1 00:00:00 1970
From: scott.bauer@intel.com (Scott Bauer)
Date: Fri, 9 Dec 2016 10:45:30 -0700
Subject: [PATCH v2 2/4] block: Add Sed-opal library
In-Reply-To: <20161201182239.GH21081@localhost.localdomain>
References: <1480456322-27339-1-git-send-email-scott.bauer@intel.com>
 <1480456322-27339-3-git-send-email-scott.bauer@intel.com>
 <20161201005006.GE21081@localhost.localdomain>
 <20161201100456.GA17592@infradead.org>
 <20161201175343.GA6554@sbauer-Z170X-UD5>
 <20161201182239.GH21081@localhost.localdomain>
Message-ID: <20161209174529.GA7865@sbauer-Z170X-UD5>

On Thu, Dec 01, 2016@01:22:39PM -0500, Keith Busch wrote:
> On Thu, Dec 01, 2016@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?