All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alison Schofield <alison.schofield@intel.com>
To: dhowells@redhat.com, tglx@linutronix.de
Cc: Kai Huang <kai.huang@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Kirill Shutemov <kirill.shutemov@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	jmorris@namei.org, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org, mingo@redhat.com,
	hpa@zytor.com, x86@kernel.org, linux-mm@kvack.org
Subject: [RFC 12/12] keys/mktme: Do not revoke in use memory encryption keys
Date: Fri, 07 Sep 2018 22:39:04 +0000	[thread overview]
Message-ID: <e8f43039bf904d0547a9fdc1f6da515747305a59.1536356108.git.alison.schofield@intel.com> (raw)
In-Reply-To: <cover.1536356108.git.alison.schofield@intel.com>

The MKTME key service maps userspace keys to hardware keyids. Those
keys are used in a new system call that encrypts memory. The keys
need to be tightly controlled. One example is that userspace keys
should not be revoked while the hardware keyid slot is still in use.

The KEY_FLAG_KEEP bit offers good control. The mktme service uses
that flag to prevent userspace keys from going away without proper
synchronization with the mktme service type.

The problem is that we need a safe and synchronous way to revoke keys.
The way .revoke methods function now, the key service type is called late
in the revoke process for cleanup after the fact. The mktme key service
has no means to consider and perhaps reject the revoke request.

This proposal inserts the MKTME revoke call earlier into the existing
keyctl <revoke> path. If it is safe to revoke the key, MKTME key service
will turn off KEY_FLAG_KEEP and let the revoke continue and succeed.
Otherwise, not safe, KEY_FLAG_KEEP stays on, which causes the normal
path of revoke to fail.

For the MKTME Key Service, a revoke may be done safely when there are
no outstanding memory mappings encrypted with the key being revoked.

Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 security/keys/internal.h   |  6 ++++++
 security/keys/keyctl.c     |  7 +++++++
 security/keys/mktme_keys.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+)

diff --git a/security/keys/internal.h b/security/keys/internal.h
index 9f8208dc0e55..9fb871522efe 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -316,4 +316,10 @@ static inline void key_check(const struct key *key)
 
 #endif
 
+#ifdef CONFIG_MKTME_KEYS
+extern void mktme_revoke_key(struct key *key);
+#else
+static inline void mktme_revoke_key(struct key *key) {}
+#endif /* CONFIG_MKTME_KEYS */
+
 #endif /* _INTERNAL_H */
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 1ffe60bb2845..86d2596ff275 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -363,6 +363,9 @@ long keyctl_update_key(key_serial_t id,
  * and any links to the key will be automatically garbage collected after a
  * certain amount of time (/proc/sys/kernel/keys/gc_delay).
  *
+ * The MKTME key service type checks if a memory encryption key is in use
+ * before allowing a revoke to proceed.
+ *
  * Keys with KEY_FLAG_KEEP set should not be revoked.
  *
  * If successful, 0 is returned.
@@ -387,6 +390,10 @@ long keyctl_revoke_key(key_serial_t id)
 
 	key = key_ref_to_ptr(key_ref);
 	ret = 0;
+
+	if (strcmp(key->type->name, "mktme") = 0)
+		mktme_revoke_key(key);
+
 	if (test_bit(KEY_FLAG_KEEP, &key->flags))
 		ret = -EPERM;
 	else
diff --git a/security/keys/mktme_keys.c b/security/keys/mktme_keys.c
index dcbce7194647..c665be860538 100644
--- a/security/keys/mktme_keys.c
+++ b/security/keys/mktme_keys.c
@@ -31,6 +31,52 @@ static const char * const mktme_program_err[] = {
 	"Failure to access key table",		/* 5 */
 };
 
+static int mktme_clear_programmed_key(int keyid)
+{
+	struct mktme_key_program *kprog = NULL;
+	int ret;
+
+	kprog = kmem_cache_zalloc(mktme_prog_cache, GFP_KERNEL);
+	if (!kprog)
+		return -ENOMEM;
+
+	kprog->keyid = keyid;
+	kprog->keyid_ctrl = MKTME_KEYID_CLEAR_KEY;
+	ret = mktme_key_program(kprog, mktme_cpumask);
+	if (ret = MKTME_PROG_SUCCESS)
+		mktme_map_clear_keyid(keyid);
+	else
+		pr_debug("mktme: %s [%d]\n", mktme_program_err[ret], ret);
+
+	kmem_cache_free(mktme_prog_cache, kprog);
+	return ret;
+}
+
+/*
+ * If the key is not in use, clear the hardware programming and
+ * allow the revoke to continue by clearing KEY_FLAG_KEEP.
+ */
+void mktme_revoke_key(struct key *key)
+{
+	int keyid, vma_count;
+
+	mktme_map_lock();
+	keyid = mktme_map_keyid_from_serial(key->serial);
+	if (keyid <= 0)
+		goto out;
+
+	vma_count = vma_read_encrypt_ref(keyid);
+	if (vma_count > 0) {
+		pr_debug("mktme not freeing keyid[%d] encrypt_count[%d]\n",
+			 keyid, vma_count);
+		goto out;
+	}
+	if (!mktme_clear_programmed_key(keyid))
+		clear_bit(KEY_FLAG_KEEP, &key->flags);
+out:
+	mktme_map_unlock();
+}
+
 /* If a key is available, program and add the key to the software map. */
 static int mktme_program_key(key_serial_t serial,
 			     struct mktme_key_program *kprog)
@@ -193,6 +239,7 @@ int mktme_instantiate(struct key *key, struct key_preparsed_payload *prep)
 
 	mktme_map_lock();
 	ret = mktme_program_key(key->serial, kprog);
+	set_bit(KEY_FLAG_KEEP, &key->flags);
 	mktme_map_unlock();
 out:
 	kzfree(options);
-- 
2.14.1

WARNING: multiple messages have this Message-ID (diff)
From: alison.schofield@intel.com (Alison Schofield)
To: linux-security-module@vger.kernel.org
Subject: [RFC 12/12] keys/mktme: Do not revoke in use memory encryption keys
Date: Fri, 7 Sep 2018 15:39:04 -0700	[thread overview]
Message-ID: <e8f43039bf904d0547a9fdc1f6da515747305a59.1536356108.git.alison.schofield@intel.com> (raw)
In-Reply-To: <cover.1536356108.git.alison.schofield@intel.com>

The MKTME key service maps userspace keys to hardware keyids. Those
keys are used in a new system call that encrypts memory. The keys
need to be tightly controlled. One example is that userspace keys
should not be revoked while the hardware keyid slot is still in use.

The KEY_FLAG_KEEP bit offers good control. The mktme service uses
that flag to prevent userspace keys from going away without proper
synchronization with the mktme service type.

The problem is that we need a safe and synchronous way to revoke keys.
The way .revoke methods function now, the key service type is called late
in the revoke process for cleanup after the fact. The mktme key service
has no means to consider and perhaps reject the revoke request.

This proposal inserts the MKTME revoke call earlier into the existing
keyctl <revoke> path. If it is safe to revoke the key, MKTME key service
will turn off KEY_FLAG_KEEP and let the revoke continue and succeed.
Otherwise, not safe, KEY_FLAG_KEEP stays on, which causes the normal
path of revoke to fail.

For the MKTME Key Service, a revoke may be done safely when there are
no outstanding memory mappings encrypted with the key being revoked.

Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 security/keys/internal.h   |  6 ++++++
 security/keys/keyctl.c     |  7 +++++++
 security/keys/mktme_keys.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+)

diff --git a/security/keys/internal.h b/security/keys/internal.h
index 9f8208dc0e55..9fb871522efe 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -316,4 +316,10 @@ static inline void key_check(const struct key *key)
 
 #endif
 
+#ifdef CONFIG_MKTME_KEYS
+extern void mktme_revoke_key(struct key *key);
+#else
+static inline void mktme_revoke_key(struct key *key) {}
+#endif /* CONFIG_MKTME_KEYS */
+
 #endif /* _INTERNAL_H */
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 1ffe60bb2845..86d2596ff275 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -363,6 +363,9 @@ long keyctl_update_key(key_serial_t id,
  * and any links to the key will be automatically garbage collected after a
  * certain amount of time (/proc/sys/kernel/keys/gc_delay).
  *
+ * The MKTME key service type checks if a memory encryption key is in use
+ * before allowing a revoke to proceed.
+ *
  * Keys with KEY_FLAG_KEEP set should not be revoked.
  *
  * If successful, 0 is returned.
@@ -387,6 +390,10 @@ long keyctl_revoke_key(key_serial_t id)
 
 	key = key_ref_to_ptr(key_ref);
 	ret = 0;
+
+	if (strcmp(key->type->name, "mktme") == 0)
+		mktme_revoke_key(key);
+
 	if (test_bit(KEY_FLAG_KEEP, &key->flags))
 		ret = -EPERM;
 	else
diff --git a/security/keys/mktme_keys.c b/security/keys/mktme_keys.c
index dcbce7194647..c665be860538 100644
--- a/security/keys/mktme_keys.c
+++ b/security/keys/mktme_keys.c
@@ -31,6 +31,52 @@ static const char * const mktme_program_err[] = {
 	"Failure to access key table",		/* 5 */
 };
 
+static int mktme_clear_programmed_key(int keyid)
+{
+	struct mktme_key_program *kprog = NULL;
+	int ret;
+
+	kprog = kmem_cache_zalloc(mktme_prog_cache, GFP_KERNEL);
+	if (!kprog)
+		return -ENOMEM;
+
+	kprog->keyid = keyid;
+	kprog->keyid_ctrl = MKTME_KEYID_CLEAR_KEY;
+	ret = mktme_key_program(kprog, mktme_cpumask);
+	if (ret == MKTME_PROG_SUCCESS)
+		mktme_map_clear_keyid(keyid);
+	else
+		pr_debug("mktme: %s [%d]\n", mktme_program_err[ret], ret);
+
+	kmem_cache_free(mktme_prog_cache, kprog);
+	return ret;
+}
+
+/*
+ * If the key is not in use, clear the hardware programming and
+ * allow the revoke to continue by clearing KEY_FLAG_KEEP.
+ */
+void mktme_revoke_key(struct key *key)
+{
+	int keyid, vma_count;
+
+	mktme_map_lock();
+	keyid = mktme_map_keyid_from_serial(key->serial);
+	if (keyid <= 0)
+		goto out;
+
+	vma_count = vma_read_encrypt_ref(keyid);
+	if (vma_count > 0) {
+		pr_debug("mktme not freeing keyid[%d] encrypt_count[%d]\n",
+			 keyid, vma_count);
+		goto out;
+	}
+	if (!mktme_clear_programmed_key(keyid))
+		clear_bit(KEY_FLAG_KEEP, &key->flags);
+out:
+	mktme_map_unlock();
+}
+
 /* If a key is available, program and add the key to the software map. */
 static int mktme_program_key(key_serial_t serial,
 			     struct mktme_key_program *kprog)
@@ -193,6 +239,7 @@ int mktme_instantiate(struct key *key, struct key_preparsed_payload *prep)
 
 	mktme_map_lock();
 	ret = mktme_program_key(key->serial, kprog);
+	set_bit(KEY_FLAG_KEEP, &key->flags);
 	mktme_map_unlock();
 out:
 	kzfree(options);
-- 
2.14.1

WARNING: multiple messages have this Message-ID (diff)
From: Alison Schofield <alison.schofield@intel.com>
To: dhowells@redhat.com, tglx@linutronix.de
Cc: Kai Huang <kai.huang@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Kirill Shutemov <kirill.shutemov@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	jmorris@namei.org, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org, mingo@redhat.com,
	hpa@zytor.com, x86@kernel.org, linux-mm@kvack.org
Subject: [RFC 12/12] keys/mktme: Do not revoke in use memory encryption keys
Date: Fri, 7 Sep 2018 15:39:04 -0700	[thread overview]
Message-ID: <e8f43039bf904d0547a9fdc1f6da515747305a59.1536356108.git.alison.schofield@intel.com> (raw)
In-Reply-To: <cover.1536356108.git.alison.schofield@intel.com>

The MKTME key service maps userspace keys to hardware keyids. Those
keys are used in a new system call that encrypts memory. The keys
need to be tightly controlled. One example is that userspace keys
should not be revoked while the hardware keyid slot is still in use.

The KEY_FLAG_KEEP bit offers good control. The mktme service uses
that flag to prevent userspace keys from going away without proper
synchronization with the mktme service type.

The problem is that we need a safe and synchronous way to revoke keys.
The way .revoke methods function now, the key service type is called late
in the revoke process for cleanup after the fact. The mktme key service
has no means to consider and perhaps reject the revoke request.

This proposal inserts the MKTME revoke call earlier into the existing
keyctl <revoke> path. If it is safe to revoke the key, MKTME key service
will turn off KEY_FLAG_KEEP and let the revoke continue and succeed.
Otherwise, not safe, KEY_FLAG_KEEP stays on, which causes the normal
path of revoke to fail.

For the MKTME Key Service, a revoke may be done safely when there are
no outstanding memory mappings encrypted with the key being revoked.

Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 security/keys/internal.h   |  6 ++++++
 security/keys/keyctl.c     |  7 +++++++
 security/keys/mktme_keys.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+)

diff --git a/security/keys/internal.h b/security/keys/internal.h
index 9f8208dc0e55..9fb871522efe 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -316,4 +316,10 @@ static inline void key_check(const struct key *key)
 
 #endif
 
+#ifdef CONFIG_MKTME_KEYS
+extern void mktme_revoke_key(struct key *key);
+#else
+static inline void mktme_revoke_key(struct key *key) {}
+#endif /* CONFIG_MKTME_KEYS */
+
 #endif /* _INTERNAL_H */
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 1ffe60bb2845..86d2596ff275 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -363,6 +363,9 @@ long keyctl_update_key(key_serial_t id,
  * and any links to the key will be automatically garbage collected after a
  * certain amount of time (/proc/sys/kernel/keys/gc_delay).
  *
+ * The MKTME key service type checks if a memory encryption key is in use
+ * before allowing a revoke to proceed.
+ *
  * Keys with KEY_FLAG_KEEP set should not be revoked.
  *
  * If successful, 0 is returned.
@@ -387,6 +390,10 @@ long keyctl_revoke_key(key_serial_t id)
 
 	key = key_ref_to_ptr(key_ref);
 	ret = 0;
+
+	if (strcmp(key->type->name, "mktme") == 0)
+		mktme_revoke_key(key);
+
 	if (test_bit(KEY_FLAG_KEEP, &key->flags))
 		ret = -EPERM;
 	else
diff --git a/security/keys/mktme_keys.c b/security/keys/mktme_keys.c
index dcbce7194647..c665be860538 100644
--- a/security/keys/mktme_keys.c
+++ b/security/keys/mktme_keys.c
@@ -31,6 +31,52 @@ static const char * const mktme_program_err[] = {
 	"Failure to access key table",		/* 5 */
 };
 
+static int mktme_clear_programmed_key(int keyid)
+{
+	struct mktme_key_program *kprog = NULL;
+	int ret;
+
+	kprog = kmem_cache_zalloc(mktme_prog_cache, GFP_KERNEL);
+	if (!kprog)
+		return -ENOMEM;
+
+	kprog->keyid = keyid;
+	kprog->keyid_ctrl = MKTME_KEYID_CLEAR_KEY;
+	ret = mktme_key_program(kprog, mktme_cpumask);
+	if (ret == MKTME_PROG_SUCCESS)
+		mktme_map_clear_keyid(keyid);
+	else
+		pr_debug("mktme: %s [%d]\n", mktme_program_err[ret], ret);
+
+	kmem_cache_free(mktme_prog_cache, kprog);
+	return ret;
+}
+
+/*
+ * If the key is not in use, clear the hardware programming and
+ * allow the revoke to continue by clearing KEY_FLAG_KEEP.
+ */
+void mktme_revoke_key(struct key *key)
+{
+	int keyid, vma_count;
+
+	mktme_map_lock();
+	keyid = mktme_map_keyid_from_serial(key->serial);
+	if (keyid <= 0)
+		goto out;
+
+	vma_count = vma_read_encrypt_ref(keyid);
+	if (vma_count > 0) {
+		pr_debug("mktme not freeing keyid[%d] encrypt_count[%d]\n",
+			 keyid, vma_count);
+		goto out;
+	}
+	if (!mktme_clear_programmed_key(keyid))
+		clear_bit(KEY_FLAG_KEEP, &key->flags);
+out:
+	mktme_map_unlock();
+}
+
 /* If a key is available, program and add the key to the software map. */
 static int mktme_program_key(key_serial_t serial,
 			     struct mktme_key_program *kprog)
@@ -193,6 +239,7 @@ int mktme_instantiate(struct key *key, struct key_preparsed_payload *prep)
 
 	mktme_map_lock();
 	ret = mktme_program_key(key->serial, kprog);
+	set_bit(KEY_FLAG_KEEP, &key->flags);
 	mktme_map_unlock();
 out:
 	kzfree(options);
-- 
2.14.1

  parent reply	other threads:[~2018-09-07 22:39 UTC|newest]

Thread overview: 159+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07 22:23 [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME) Alison Schofield
2018-09-07 22:23 ` Alison Schofield
2018-09-07 22:23 ` Alison Schofield
2018-09-07 22:34 ` [RFC 01/12] docs/x86: Document the Multi-Key Total Memory Encryption API Alison Schofield
2018-09-08 18:44   ` Randy Dunlap
2018-09-08 18:44     ` Randy Dunlap
2018-09-08 18:44     ` Randy Dunlap
2018-09-10  1:28   ` Huang, Kai
2018-09-10  1:28     ` Huang, Kai
2018-09-10  1:28     ` Huang, Kai
2018-09-11  0:13     ` Alison Schofield
2018-09-11  0:13       ` Alison Schofield
2018-09-11  0:13       ` Alison Schofield
2018-09-11  0:33       ` Huang, Kai
2018-09-11  0:33         ` Huang, Kai
2018-09-11  0:33         ` Huang, Kai
2018-09-11  0:45         ` Alison Schofield
2018-09-11  0:45           ` Alison Schofield
2018-09-11  0:45           ` Alison Schofield
2018-09-11  1:14           ` Huang, Kai
2018-09-11  1:14             ` Huang, Kai
2018-09-11  1:14             ` Huang, Kai
2018-09-11  0:14     ` Huang, Kai
2018-09-11  0:14       ` Huang, Kai
2018-09-11  0:14       ` Huang, Kai
2018-09-10 17:32   ` Sakkinen, Jarkko
2018-09-10 17:32     ` Sakkinen, Jarkko
2018-09-10 17:32     ` Sakkinen, Jarkko
2018-09-11  0:19     ` Alison Schofield
2018-09-11  0:19       ` Alison Schofield
2018-09-11  0:19       ` Alison Schofield
2018-09-07 22:34 ` [RFC 02/12] mm: Generalize the mprotect implementation to support extensions Alison Schofield
2018-09-07 22:34   ` Alison Schofield
2018-09-07 22:34   ` Alison Schofield
2018-09-10 10:12   ` Jarkko Sakkinen
2018-09-10 10:12     ` Jarkko Sakkinen
2018-09-10 10:12     ` Jarkko Sakkinen
2018-09-11  0:34     ` Alison Schofield
2018-09-11  0:34       ` Alison Schofield
2018-09-11  0:34       ` Alison Schofield
2018-09-07 22:34 ` [RFC 03/12] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield
2018-09-07 22:34   ` Alison Schofield
2018-09-07 22:34   ` Alison Schofield
2018-09-07 22:36 ` [RFC 04/12] x86/mm: Add helper functions to manage " Alison Schofield
2018-09-07 22:36   ` Alison Schofield
2018-09-07 22:36   ` Alison Schofield
2018-09-10  2:56   ` Huang, Kai
2018-09-10  2:56     ` Huang, Kai
2018-09-10  2:56     ` Huang, Kai
2018-09-10 23:37     ` Huang, Kai
2018-09-10 23:37       ` Huang, Kai
2018-09-10 23:37       ` Huang, Kai
2018-09-10 23:41       ` Alison Schofield
2018-09-10 23:41         ` Alison Schofield
2018-09-10 23:41         ` Alison Schofield
2018-09-10 17:37   ` Sakkinen, Jarkko
2018-09-07 22:36 ` [RFC 05/12] x86/mm: Add a helper function to set keyid bits in encrypted VMA's Alison Schofield
2018-09-07 22:36   ` Alison Schofield
2018-09-07 22:36   ` Alison Schofield
2018-09-10 17:57   ` Sakkinen, Jarkko
2018-09-10 17:57     ` Sakkinen, Jarkko
2018-09-10 17:57     ` Sakkinen, Jarkko
2018-09-07 22:36 ` [RFC 06/12] mm: Add the encrypt_mprotect() system call Alison Schofield
2018-09-10 18:02   ` Jarkko Sakkinen
2018-09-10 18:02     ` Jarkko Sakkinen
2018-09-10 18:02     ` Jarkko Sakkinen
2018-09-11  2:15     ` Alison Schofield
2018-09-11  2:15       ` Alison Schofield
2018-09-11  2:15       ` Alison Schofield
2018-09-07 22:37 ` [RFC 07/12] x86/mm: Add helper functions to track encrypted VMA's Alison Schofield
2018-09-07 22:37   ` Alison Schofield
2018-09-07 22:37   ` Alison Schofield
2018-09-10  3:17   ` Huang, Kai
2018-09-10  3:17     ` Huang, Kai
2018-09-07 22:37 ` [RFC 08/12] mm: Track VMA's in use for each memory encryption keyid Alison Schofield
2018-09-07 22:37   ` Alison Schofield
2018-09-07 22:37   ` Alison Schofield
2018-09-10 18:20   ` Jarkko Sakkinen
2018-09-10 18:20     ` Jarkko Sakkinen
2018-09-10 18:20     ` Jarkko Sakkinen
2018-09-11  2:39     ` Alison Schofield
2018-09-11  2:39       ` Alison Schofield
2018-09-11  2:39       ` Alison Schofield
2018-09-07 22:37 ` [RFC 09/12] mm: Restrict memory encryption to anonymous VMA's Alison Schofield
2018-09-07 22:37   ` Alison Schofield
2018-09-07 22:37   ` Alison Schofield
2018-09-10 18:21   ` Sakkinen, Jarkko
2018-09-10 18:21     ` Sakkinen, Jarkko
2018-09-10 18:21     ` Sakkinen, Jarkko
2018-09-10 18:57     ` Dave Hansen
2018-09-10 18:57       ` Dave Hansen
2018-09-10 18:57       ` Dave Hansen
2018-09-10 21:07       ` Jarkko Sakkinen
2018-09-10 21:07         ` Jarkko Sakkinen
2018-09-10 21:07         ` Jarkko Sakkinen
2018-09-10 21:09         ` Dave Hansen
2018-09-10 21:09           ` Dave Hansen
2018-09-10 21:09           ` Dave Hansen
2018-09-07 22:38 ` [RFC 10/12] x86/pconfig: Program memory encryption keys on a system-wide basis Alison Schofield
2018-09-07 22:38   ` Alison Schofield
2018-09-07 22:38   ` Alison Schofield
2018-09-10  1:46   ` Huang, Kai
2018-09-10  1:46     ` Huang, Kai
2018-09-10 18:24   ` Sakkinen, Jarkko
2018-09-10 18:24     ` Sakkinen, Jarkko
2018-09-10 18:24     ` Sakkinen, Jarkko
2018-09-11  2:46     ` Alison Schofield
2018-09-11  2:46       ` Alison Schofield
2018-09-11  2:46       ` Alison Schofield
2018-09-11 14:31       ` Jarkko Sakkinen
2018-09-11 14:31         ` Jarkko Sakkinen
2018-09-11 14:31         ` Jarkko Sakkinen
2018-09-07 22:38 ` [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys Alison Schofield
2018-09-07 22:38   ` Alison Schofield
2018-09-07 22:38   ` Alison Schofield
2018-09-10  3:29   ` Huang, Kai
2018-09-10  3:29     ` Huang, Kai
2018-09-10  3:29     ` Huang, Kai
2018-09-10 21:47     ` Alison Schofield
2018-09-10 21:47       ` Alison Schofield
2018-09-10 21:47       ` Alison Schofield
2018-09-15  0:06     ` Alison Schofield
2018-09-15  0:06       ` Alison Schofield
2018-09-15  0:06       ` Alison Schofield
2018-09-17 10:48       ` Huang, Kai
2018-09-17 10:48         ` Huang, Kai
2018-09-17 10:48         ` Huang, Kai
2018-09-17 22:34         ` Huang, Kai
2018-09-17 22:34           ` Huang, Kai
2018-09-17 22:34           ` Huang, Kai
2018-09-07 22:39 ` Alison Schofield [this message]
2018-09-07 22:39   ` [RFC 12/12] keys/mktme: Do not revoke in use " Alison Schofield
2018-09-07 22:39   ` Alison Schofield
2018-09-10  1:10 ` [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME) Huang, Kai
2018-09-10  1:10   ` Huang, Kai
2018-09-10 19:10   ` Alison Schofield
2018-09-10 19:10     ` Alison Schofield
2018-09-10 19:10     ` Alison Schofield
2018-09-11  3:15     ` Huang, Kai
2018-09-11  3:15       ` Huang, Kai
2018-09-11  3:15       ` Huang, Kai
2018-09-10 17:29 ` Sakkinen, Jarkko
2018-09-10 17:29   ` Sakkinen, Jarkko
2018-09-10 17:29   ` Sakkinen, Jarkko
2018-09-11 22:03 ` [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys David Howells
2018-09-11 22:03   ` David Howells
2018-09-11 22:03   ` David Howells
2018-09-11 22:39   ` Alison Schofield
2018-09-11 22:39     ` Alison Schofield
2018-09-11 22:39     ` Alison Schofield
2018-09-11 23:01   ` David Howells
2018-09-11 23:01     ` David Howells
2018-09-11 23:01     ` David Howells
2018-09-11 22:56 ` [RFC 04/12] x86/mm: Add helper functions to manage " David Howells
2018-09-11 22:56   ` David Howells
2018-09-11 22:56   ` David Howells
2018-09-12 11:12 ` [RFC 12/12] keys/mktme: Do not revoke in use " David Howells
2018-09-12 11:12   ` David Howells
2018-09-12 11:12   ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e8f43039bf904d0547a9fdc1f6da515747305a59.1536356108.git.alison.schofield@intel.com \
    --to=alison.schofield@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dhowells@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@intel.com \
    --cc=jmorris@namei.org \
    --cc=jun.nakajima@intel.com \
    --cc=kai.huang@intel.com \
    --cc=keyrings@vger.kernel.org \
    --cc=kirill.shutemov@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.