@@ -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 */
@@ -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
@@ -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);
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(+)