Thread (42 messages) 42 messages, 6 authors, 2018-09-17

[RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys

flat view

From: alison.schofield@intel.com (Alison Schofield)
Date: 2018-09-10 21:47:00
Also in: keyrings, linux-mm

On Sun, Sep 09, 2018 at 08:29:29PM -0700, Huang, Kai wrote:
quoted
-----Original Message-----
From: keyrings-owner at vger.kernel.org [mailto:keyrings-
owner at vger.kernel.org] On Behalf Of Alison Schofield
Sent: Saturday, September 8, 2018 10:39 AM
To: dhowells at redhat.com; tglx at linutronix.de
Cc: Huang, Kai <redacted>; Nakajima, Jun
[off-list ref]; Shutemov, Kirill [off-list ref];
Hansen, Dave [off-list ref]; Sakkinen, Jarkko
[off-list ref]; jmorris at namei.org; keyrings at vger.kernel.org;
linux-security-module at vger.kernel.org; mingo at redhat.com; hpa at zytor.com;
x86 at kernel.org; linux-mm at kvack.org
Subject: [RFC 11/12] keys/mktme: Add a new key service type for memory
encryption keys

MKTME (Multi-Key Total Memory Encryption) is a technology that allows
transparent memory encryption in upcoming Intel platforms. MKTME will
support mulitple encryption domains, each having their own key. The main use
case for the feature is virtual machine isolation. The API needs the flexibility to
work for a wide range of uses.

The MKTME key service type manages the addition and removal of the memory
encryption keys. It maps software keys to hardware keyids and programs the
hardware with the user requested encryption options.

The only supported encryption algorithm is AES-XTS 128.

The MKTME key service is half of the MKTME API level solution. It pairs with a
new memory encryption system call: encrypt_mprotect() that uses the keys to
encrypt memory.

Kai -
Splitting out responses by subject...
quoted
+cpumask_var_t mktme_cpumask;		/* one cpu per pkg to program
keys */
Oh the 'mktme_cpumask' is here. Sorry I didn't notice when replying to your patch 10. :)

But I think you can just move what you did in patch 10 here and leave intel_pconfig.h unchanged. It's much clearer. 
I'll try that out and see how it works.
quoted
+
+	for_each_online_cpu(online_cpu) {
+		online_pkgid = topology_physical_package_id(online_cpu);
+
+		for_each_cpu(mktme_cpu, mktme_cpumask) {
+			mktme_pkgid =
topology_physical_package_id(mktme_cpu);
+			if (mktme_pkgid == online_pkgid)
+				break;
+		}
+		if (mktme_pkgid != online_pkgid)
+			cpumask_set_cpu(online_cpu, mktme_cpumask);
+	}
Could we use 'for_each_online_node', 'cpumask_first/next', etc to simplify the logic?
Sure - I'll look at those. 

Thanks!
Alison
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help