Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1385524 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] Add Opal unlock support to NVMe. Rafael Antognolli <rafael.antognolli@intel.com> - 2016-04-23 01:20 +0200
    [PATCH 2/2] NVMe: Add ioctls to save and unlock an Opal locking range. Rafael Antognolli <rafael.antognolli@intel.com> - 2016-04-23 01:20 +0200
    Re: [PATCH 0/2] Add Opal unlock support to NVMe. Christoph Hellwig <hch@infradead.org> - 2016-04-25 10:30 +0200
      RE: [PATCH 0/2] Add Opal unlock support to NVMe. "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> - 2016-04-26 05:30 +0200
        Re: [PATCH 0/2] Add Opal unlock support to NVMe. Rafael Antognolli <rafael.antognolli@intel.com> - 2016-04-26 23:40 +0200

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

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

[toc] | [next] | [standalone]

#1385527 — [PATCH 2/2] NVMe: Add ioctls to save and unlock an Opal locking range.

Two ioctls are added to the NVMe namespace: NVME_IOCTL_SAVE_OPAL_KEY and
NVME_IOCTL_UNLOCK_OPAL. These ioctls map directly to the respective
nvme_opal_register() and nvme_opal_unlock() functions.

Additionally, nvme_opal_unlock() is called upon nvme_revalidate_disk, so it
will try to unlock a locking range (if a password for it is saved) during PM
resume.

Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
---
 drivers/nvme/host/core.c        | 9 +++++++++
 include/uapi/linux/nvme_ioctl.h | 7 +++++++
 2 files changed, 16 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 643f457..1f4b78c 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -30,6 +30,7 @@
 #include <asm/unaligned.h>
 
 #include "nvme.h"
+#include "opal.h"
 
 #define NVME_MINORS		(1U << MINORBITS)
 
@@ -517,6 +518,10 @@ static int nvme_ioctl(struct block_device *bdev, fmode_t mode,
 	case SG_IO:
 		return nvme_sg_io(ns, (void __user *)arg);
 #endif
+	case NVME_IOCTL_SAVE_OPAL_KEY:
+		return nvme_opal_register(ns, (void __user *)arg);
+	case NVME_IOCTL_UNLOCK_OPAL:
+		return nvme_opal_unlock(ns);
 	default:
 		return -ENOTTY;
 	}
@@ -675,6 +680,7 @@ static int nvme_revalidate_disk(struct gendisk *disk)
 	if (ns->ctrl->oncs & NVME_CTRL_ONCS_DSM)
 		nvme_config_discard(ns);
 	blk_mq_unfreeze_queue(disk->queue);
+	nvme_opal_unlock(ns);
 
 	kfree(id);
 	return 0;
@@ -1596,6 +1602,8 @@ int __init nvme_core_init(void)
 		goto unregister_chrdev;
 	}
 
+	nvme_opal_init();
+
 	return 0;
 
  unregister_chrdev:
@@ -1607,6 +1615,7 @@ int __init nvme_core_init(void)
 
 void nvme_core_exit(void)
 {
+	nvme_opal_exit();
 	unregister_blkdev(nvme_major, "nvme");
 	class_destroy(nvme_class);
 	__unregister_chrdev(nvme_char_major, 0, NVME_MINORS, "nvme");
diff --git a/include/uapi/linux/nvme_ioctl.h b/include/uapi/linux/nvme_ioctl.h
index c4b2a3f..8f8ab02 100644
--- a/include/uapi/linux/nvme_ioctl.h
+++ b/include/uapi/linux/nvme_ioctl.h
@@ -53,6 +53,11 @@ struct nvme_passthru_cmd {
 	__u32	result;
 };
 
+struct nvme_opal_key {
+	__u8	locking_range;
+	__u8	key[256];
+};
+
 #define nvme_admin_cmd nvme_passthru_cmd
 
 #define NVME_IOCTL_ID		_IO('N', 0x40)
@@ -61,5 +66,7 @@ struct nvme_passthru_cmd {
 #define NVME_IOCTL_IO_CMD	_IOWR('N', 0x43, struct nvme_passthru_cmd)
 #define NVME_IOCTL_RESET	_IO('N', 0x44)
 #define NVME_IOCTL_SUBSYS_RESET	_IO('N', 0x45)
+#define NVME_IOCTL_SAVE_OPAL_KEY _IOW('N', 0X46, struct nvme_opal_key)
+#define NVME_IOCTL_UNLOCK_OPAL  _IO('N', 0X47)
 
 #endif /* _UAPI_LINUX_NVME_IOCTL_H */
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1386101

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.

[toc] | [prev] | [next] | [standalone]

#1387116

> -----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.

[toc] | [prev] | [next] | [standalone]

#1388117

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web