[PATCH 0/2] Add Opal unlock support to NVMe.

[PATCH 0/2] Add Opal unlock support to NVMe.

[Rafael Antognolli]

This patch series implement a small set of the Opal protocol for self
encrypting devices. It's implemented only what is needed for saving a password
and unlocking a given "locking range". The password is saved on the driver and
replayed back to the device on resume from suspend to RAM. It is specifically
supporting the single user mode.

It is not planned to implement the full Opal protocol (at least not for now).

Rafael Antognolli (2):
  Add optane OPAL unlocking code.
  NVMe: Add ioctls to save and unlock an Opal locking range.

 drivers/nvme/host/Kconfig         |    7 +
 drivers/nvme/host/Makefile        |    1 +
 drivers/nvme/host/core.c          |    9 +
 drivers/nvme/host/opal.c          | 1270 +++++++++++++++++++++++++++++++++++++
 drivers/nvme/host/opal.h          |   73 +++
 drivers/nvme/host/opal_internal.h |  501 +++++++++++++++
 include/uapi/linux/nvme_ioctl.h   |    7 +
 7 files changed, 1868 insertions(+)
 create mode 100644 drivers/nvme/host/opal.c
 create mode 100644 drivers/nvme/host/opal.h
 create mode 100644 drivers/nvme/host/opal_internal.h

-- 
1.9.1

Re: [PATCH 0/2] Add Opal unlock support to NVMe.

[Christoph Hellwig]

On Fri, Apr 22, 2016 at 04:12:10PM -0700, Rafael Antognolli wrote:
> This patch series implement a small set of the Opal protocol for self
> encrypting devices. It's implemented only what is needed for saving a password
> and unlocking a given "locking range". The password is saved on the driver and
> replayed back to the device on resume from suspend to RAM. It is specifically
> supporting the single user mode.
> 
> It is not planned to implement the full Opal protocol (at least not for now).

I think the OPAL code should be a generic library outside the NVMe
code so that we can use it for SATA and SAS as well, just with a little
glue code for the Security Send / Receive commands to wire it up to
NVMe.

RE: [PATCH 0/2] Add Opal unlock support to NVMe.

[Elliott, Robert (Persistent Memory)]

> -----Original Message-----
> From: linux-block-owner@vger.kernel.org [mailto:linux-block-
> owner@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Monday, April 25, 2016 3:24 AM
> To: Rafael Antognolli <rafael.antognolli@intel.com>
> Cc: linux-nvme@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-block@vger.kernel.org
> Subject: Re: [PATCH 0/2] Add Opal unlock support to NVMe.
> 
> On Fri, Apr 22, 2016 at 04:12:10PM -0700, Rafael Antognolli wrote:
> > This patch series implement a small set of the Opal protocol for
> > self encrypting devices. It's implemented only what is needed for
> > saving a password and unlocking a given "locking range". The
> > password is saved on the driver and replayed back to the device
> > on resume from suspend to RAM. It is specifically supporting
> > the single user mode.

Passwords stored in memory are subject to cold boot attacks.

Could you tie this into the keyring infrastructure, so it would
least be no worse than other kernel modules?  This would allow
support for TPM-based keys (if present) to resist more attacks.
If register-based key storage or other techniques prove viable,
they would probably show up there first.

> > It is not planned to implement the full Opal protocol (at least
> > not for now).
> 
> I think the OPAL code should be a generic library outside the NVMe
> code so that we can use it for SATA and SAS as well, just with a
> little glue code for the Security Send / Receive commands to wire
> it up to NVMe.

NVDIMMs would benefit from that as well.

Re: [PATCH 0/2] Add Opal unlock support to NVMe.

[Rafael Antognolli]

On Mon, Apr 25, 2016 at 08:29:22PM -0700, Elliott, Robert (Persistent Memory) wrote:
> 
> 
> > -----Original Message-----
> > From: linux-block-owner@vger.kernel.org [mailto:linux-block-
> > owner@vger.kernel.org] On Behalf Of Christoph Hellwig
> > Sent: Monday, April 25, 2016 3:24 AM
> > To: Rafael Antognolli <rafael.antognolli@intel.com>
> > Cc: linux-nvme@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux-block@vger.kernel.org
> > Subject: Re: [PATCH 0/2] Add Opal unlock support to NVMe.
> >
> > On Fri, Apr 22, 2016 at 04:12:10PM -0700, Rafael Antognolli wrote:
> > > This patch series implement a small set of the Opal protocol for
> > > self encrypting devices. It's implemented only what is needed for
> > > saving a password and unlocking a given "locking range". The
> > > password is saved on the driver and replayed back to the device
> > > on resume from suspend to RAM. It is specifically supporting
> > > the single user mode.
> 
> Passwords stored in memory are subject to cold boot attacks.
> 
> Could you tie this into the keyring infrastructure, so it would
> least be no worse than other kernel modules?  This would allow
> support for TPM-based keys (if present) to resist more attacks.
> If register-based key storage or other techniques prove viable,
> they would probably show up there first.

I'll take a look at it.

> > > It is not planned to implement the full Opal protocol (at least
> > > not for now).
> >
> > I think the OPAL code should be a generic library outside the NVMe
> > code so that we can use it for SATA and SAS as well, just with a
> > little glue code for the Security Send / Receive commands to wire
> > it up to NVMe.
> 
> NVDIMMs would benefit from that as well.

Yes, I can definitely change it to be that generic.

Thank you,
Rafael

Re: [PATCH 0/2] Add Opal unlock support to NVMe.

[Rafael Antognolli]

On Tue, Apr 26, 2016 at 02:33:49PM -0700, Rafael Antognolli wrote:
> On Mon, Apr 25, 2016 at 08:29:22PM -0700, Elliott, Robert (Persistent Memory) wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: linux-block-owner@vger.kernel.org [mailto:linux-block-
> > > owner@vger.kernel.org] On Behalf Of Christoph Hellwig
> > > Sent: Monday, April 25, 2016 3:24 AM
> > > To: Rafael Antognolli <rafael.antognolli@intel.com>
> > > Cc: linux-nvme@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux-block@vger.kernel.org
> > > Subject: Re: [PATCH 0/2] Add Opal unlock support to NVMe.
> > >
> > > On Fri, Apr 22, 2016 at 04:12:10PM -0700, Rafael Antognolli wrote:
> > > > This patch series implement a small set of the Opal protocol for
> > > > self encrypting devices. It's implemented only what is needed for
> > > > saving a password and unlocking a given "locking range". The
> > > > password is saved on the driver and replayed back to the device
> > > > on resume from suspend to RAM. It is specifically supporting
> > > > the single user mode.
> > 
> > Passwords stored in memory are subject to cold boot attacks.
> > 
> > Could you tie this into the keyring infrastructure, so it would
> > least be no worse than other kernel modules?  This would allow
> > support for TPM-based keys (if present) to resist more attacks.
> > If register-based key storage or other techniques prove viable,
> > they would probably show up there first.
> 
> I'll take a look at it.

Hi Robert, I've been looking at possibilities to integrate this into the
keyring infra as you suggested, particularly with the trusted
(TPM-based) and/or encrypted key types. However, these key types do not
support any way of loading a key from userspace; the API for creating
trusted or encrypted keys generate them inside the kernel and it's never
available to userspace. And at the same time, the current utility to set
a password on Opal devices (sedutil [1]) is a userspace program.

I could not find an easy way to connect both things unless, for
instance, I generated a trusted key that the Opal kernel code can
access, and used that key to encrypt the password to the Opal device.
That would work but would mean the user has to request a
trusted/encrypted key to be created, and then point to that when
requesting to save the password. IMHO the API of this module would start
to be a bit tricky.

Another solution would be to add support to at least encrypted or
trusted keys to be loaded from userspace (as unencrypted keys, not
encrypted blobs), even if they never get available again to userspace.
This should be easy to do, I'm just not sure if it would make sense to
have that on the trusted/encrypted keys.

And yet another solution would be to implement a lot more of the Opal
protocol in this module, and make it support setting up the locking
ranges and passwords (trusted/encrypted keys that the userspace never
saw unencrypted). But at least for now, my intention was to implement
just the least needed to unlock devices, not really implement the whole
OPAL spec.

Anyway, do you see other options, or would you mind giving your opinion
about this?

[1]: https://github.com/Drive-Trust-Alliance/sedutil

Thank you,
Rafael