From nobody Thu Mar 28 12:01:06 2024
Delivered-To: importer@patchew.org
Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28
as permitted sender) client-ip=209.132.183.28;
envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com;
Authentication-Results: mx.zohomail.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=fail(p=none dis=none) header.from=intel.com
ARC-Seal: i=1; a=rsa-sha256; t=1556746944; cv=none;
d=zoho.com; s=zohoarc;
b=N6ApC/4JS9fFmeL3IcwhY82dLwPsTLzM02Xsn91jWoXV38zVFX/FLgbyqfd6N9sIkR++/XzxgO1zPb1mzsHQEMvBQNdoNjIs1u+yFSVbtwBKl0/ErQJmQg1D+x9sk3GSZdM+yZjGYP8W9ews21GoAmRO0IiiHR9Jb+3k82NHnak=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc;
t=1556746944;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results;
bh=C0Imq/UJMgjrg8K/j7ZjatlHYT890OSyQn35MXQcslU=;
b=NhKssinyunsGQvtXKDDyLmkhDAG7hRCOHg9hUUUyosF5QjSDsagWv4Amm/PfPfvKcqyvOJBW5PoRct/kS2UDw6BW6lQyzYq8BepjCXdcc3evbl6a7oZJuMpjzxEMVaq2/7EW5/x5QTsrFR2rZ2cjfsQNrWn4d1Ar/kdm/pOLXNs=
ARC-Authentication-Results: i=1; mx.zoho.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=fail header.from= (p=none dis=none)
header.from=
Return-Path:
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by
mx.zohomail.com
with SMTPS id 1556746944330478.23636711931067;
Wed, 1 May 2019 14:42:24 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
[10.5.11.12])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 43C2AC04959E;
Wed, 1 May 2019 21:42:20 +0000 (UTC)
Received: from colo-mx.corp.redhat.com
(colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20])
by smtp.corp.redhat.com (Postfix) with ESMTPS id B8C617F81A;
Wed, 1 May 2019 21:42:17 +0000 (UTC)
Received: from lists01.pubmisc.prod.ext.phx2.redhat.com
(lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33])
by colo-mx.corp.redhat.com (Postfix) with ESMTP id 97BB918089CB;
Wed, 1 May 2019 21:42:13 +0000 (UTC)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com
[10.5.11.16])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id x41LgBPi015981 for ;
Wed, 1 May 2019 17:42:11 -0400
Received: by smtp.corp.redhat.com (Postfix)
id 0608E78574; Wed, 1 May 2019 21:42:11 +0000 (UTC)
Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com
[10.5.110.26])
by smtp.corp.redhat.com (Postfix) with ESMTPS id C04BC7754F;
Wed, 1 May 2019 21:42:08 +0000 (UTC)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id BC28E86658;
Wed, 1 May 2019 21:42:01 +0000 (UTC)
Received: from orsmga006.jf.intel.com ([10.7.209.51])
by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
01 May 2019 14:42:00 -0700
Received: from llcarval-mobl1.amr.corp.intel.com ([10.3.52.60])
by orsmga006.jf.intel.com with ESMTP; 01 May 2019 14:41:59 -0700
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,419,1549958400"; d="scan'208";a="140486144"
From: Larkins Carvalho
To: libvir-list@redhat.com
Date: Wed, 1 May 2019 14:41:57 -0700
Message-Id: <20190501214157.10448-1-larkins.l.carvalho@intel.com>
MIME-Version: 1.0
X-Greylist: Sender passed SPF test, Sender IP whitelisted by DNSRBL, ACL 216
matched, not delayed by milter-greylist-4.5.16 (mx1.redhat.com
[10.5.110.26]); Wed, 01 May 2019 21:42:02 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com
[10.5.110.26]);
Wed, 01 May 2019 21:42:02 +0000 (UTC) for IP:'134.134.136.20'
DOMAIN:'mga02.intel.com' HELO:'mga02.intel.com'
FROM:'larkins.l.carvalho@intel.com' RCPT:''
X-RedHat-Spam-Score: -2.301 (RCVD_IN_DNSWL_MED,
SPF_PASS) 134.134.136.20 mga02.intel.com 134.134.136.20
mga02.intel.com
X-Scanned-By: MIMEDefang 2.78 on 10.5.110.26
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-loop: libvir-list@redhat.com
Cc: karimullah.mohammed@intel.com
Subject: [libvirt] [PATCH] x86: Multi-key Total Memory Encryption (Intel)
X-BeenThere: libvir-list@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
List-Id: Development discussions about the libvirt library & tools
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted,
not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]);
Wed, 01 May 2019 21:42:21 +0000 (UTC)
From: llcarval
Total Memory Encryption (TME) =E2=80=93 provides the capability to encrypt =
the
entirety of the physical memory of a system. MKTME builds on TME and
adds support for multiple encryption keys.
High Level flow:
1. Management tool calls virNodeGetMKTMEInfo. This returns an XML document
that includes the following
...
2. Management tool requests to start a guest calling virCreateXML(). The xm=
l would include
m0
user
samplekey
aes-xts-128
3. Libvirt makes system call with the provided information to generate a ke=
y handle using linux keyring services.
Qemu uses the key handle to launch the workload.
4. Libvirt generate the QEMU cli arg to enable the MKTME feature, a typical
args looks like this:
-machine memory-encryption=3Dm0 \
-object mktme-guest,id=3Dm0,handle=3D${serial}
Intel MKTME spec: https://software.intel.com/sites/default/files/managed/a5=
/16/Multi-Key-Total-Memory-Encryption-Spec.pdf
WIP: Qemu and KVM patch to support Intel MKTME are in the process of develo=
pment and community approval.
The purpose of this initial review is to get on par with libvirt developmen=
t and the proposed Intel MKTME feature in libvirt.
Considering we have not added tests, this is a preliminary patch and based =
on the community feedback, we expect more updates to follow.
TODO:
Add tests for launch security of type mktme.
Update domaincommon.rng to add attribute of type mktme.
---
docs/formatdomain.html.in | 62 +-
docs/formatdomaincaps.html.in | 18 +
docs/schemas/domaincaps.rng | 14 +
include/libvirt/libvirt-host.h | 18 +
src/conf/domain_capabilities.c | 29 +
src/conf/domain_capabilities.h | 12 +
src/conf/domain_conf.c | 114 +-
src/conf/domain_conf.h | 13 +
src/conf/virconftypes.h | 3 +
src/driver-hypervisor.h | 7 +
src/libvirt-host.c | 48 +
src/libvirt_private.syms | 5 +
src/libvirt_public.syms | 5 +
src/qemu/qemu_capabilities.c | 130 +-
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_capspriv.h | 4 +
src/qemu/qemu_command.c | 40 +
src/qemu/qemu_driver.c | 63 +
src/qemu/qemu_monitor.c | 9 +
src/qemu/qemu_monitor.h | 5 +
src/qemu/qemu_monitor_json.c | 52 +
src/qemu/qemu_monitor_json.h | 3 +
src/remote/remote_daemon_dispatch.c | 43 +
src/remote/remote_driver.c | 40 +-
src/remote/remote_protocol.x | 21 +-
src/remote_protocol-structs | 12 +
src/util/Makefile.inc.am | 2 +
src/util/virmktme.c | 112 ++
src/util/virmktme.h | 33 +
.../bhyve_basic.x86_64.xml | 1 +
.../bhyve_fbuf.x86_64.xml | 1 +
.../bhyve_uefi.x86_64.xml | 1 +
tests/domaincapsschemadata/empty.xml | 1 +
tests/domaincapsschemadata/libxl-xenfv.xml | 1 +
tests/domaincapsschemadata/libxl-xenpv.xml | 1 +
.../qemu_1.7.0.x86_64.xml | 1 +
.../qemu_2.12.0-virt.aarch64.xml | 1 +
.../qemu_2.12.0.ppc64.xml | 1 +
.../qemu_2.12.0.s390x.xml | 1 +
.../qemu_2.12.0.x86_64.xml | 1 +
.../qemu_2.6.0-virt.aarch64.xml | 1 +
.../qemu_2.6.0.aarch64.xml | 1 +
.../domaincapsschemadata/qemu_2.6.0.ppc64.xml | 1 +
.../qemu_2.6.0.x86_64.xml | 1 +
.../domaincapsschemadata/qemu_2.7.0.s390x.xml | 1 +
.../qemu_2.8.0-tcg.x86_64.xml | 1 +
.../domaincapsschemadata/qemu_2.8.0.s390x.xml | 1 +
.../qemu_2.8.0.x86_64.xml | 1 +
.../qemu_2.9.0-q35.x86_64.xml | 1 +
.../qemu_2.9.0-tcg.x86_64.xml | 1 +
.../qemu_2.9.0.x86_64.xml | 1 +
.../domaincapsschemadata/qemu_3.0.0.s390x.xml | 1 +
.../qemu_3.1.0.x86_64.xml | 1 +
.../qemu_4.0.0.x86_64.xml | 1 +
.../qemu_5.0.0.x86_64.xml | 164 ++
tests/domaincapstest.c | 4 +
.../caps_5.0.0.x86_64.xml | 1389 +++++++++++++++++
57 files changed, 2490 insertions(+), 13 deletions(-)
create mode 100644 src/util/virmktme.c
create mode 100644 src/util/virmktme.h
create mode 100644 tests/domaincapsschemadata/qemu_5.0.0.x86_64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index e1da878fcc..e96186aba9 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8924,13 +8924,16 @@ qemu-kvm -net nic,model=3D? /dev/null
=20
Note: DEA/TDEA is synonymous with DES/TDES.
=20
-
+
=20
- The contents of the <launchSecurity type=3D'sev'>
element
+ The contents of the launchSecurity
element
is used to provide the guest owners input used for creating an encr=
ypted
- VM using the AMD SEV feature (Secure Encrypted Virtualization).
-
+ VM using the AMD SEV feature (Secure Encrypted Virtualization)
+ and Intel MKTME (Multi-Key Total Memory Encryption).
+
+
+
SEV is an extension to the AMD-V architecture which supports running
encrypted virtual machine (VMs) under the control of KVM. Encrypted
VMs have their pages (code and data) secured such that only the gue=
st
@@ -8942,7 +8945,7 @@ qemu-kvm -net nic,model=3D? /dev/null
For more information see various input parameters and its format se=
e the
SEV API spec
Since 4.4.0
-
+
<domain>
...
@@ -9039,6 +9042,55 @@ qemu-kvm -net nic,model=3D? /dev/null
=20
+
+
+ Total Memory Encryption (TME) =E2=80=93 provides the capability to e=
ncrypt the
+ entirety of the physical memory of a system. MKTME builds on TME and
+ adds support for multiple encryption keys.
+
+ By default MKTME uses the TME encryption key unless explicitly specified
+ by software. In addition to supporting a CPU generated ephemeral
+ key (not accessible by software or by using external interfaces to a=
n SOC),
+ MKTME also supports software provided keys. Software provided keys are
+ particularly useful when used with nonvolatile memory or when combined
+ with attestation mechanisms and/or used with key provisioning services.
+
+ For more information see
+ MKTME spec
+ Since 5.3.0
+
+
+<domain>
+ ...
+ <launchSecurity type=3D'mktme'>
+ <id>mktme-0</id>
+ <key_type>samplekey</key_type>
+ <type>user</type>
+ <encryption_algorithm>aes-xts-128</encryption_algorithm>
+ </launchSecurity>
+ ...
+</domain>
+
+
+ id
+ - The required
id
element provides ability to map the=
key handle.
+ If the id exists system returns the same mapped key handle which can be=
used to=20
+ encrpyt a different guest.=20
+
+ key_type
+ - MKTME supports user and cpu generated keys. The required
k=
ey_type
+ element provides the type of key used for the encryption.
+
+ key
+ - The optional
key
element provides the key used for =
the encryption.
+ Required only when the key type is of user.
+
+ encryption_algorithm
+ - The required
encyption_algorithm
element provides t=
he type of=20
+ encryption algorithm. Currently, MKTME supports aes-xts-128 only.
+
+
+
=20
diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
index b31b1729f4..ece891fa67 100644
--- a/docs/formatdomaincaps.html.in
+++ b/docs/formatdomaincaps.html.in
@@ -530,5 +530,23 @@
address space. The number of bits we lose is hypervisor dependent.=
dd>
=20
+
+
+ Intel Multi-Key Total Memory Encryption (MKTME) capabilities are ex=
posed under
+ the mktme
element.
+ Total Memory Encryption (TME) =E2=80=93 provides the capability to enc=
rypt the
+ entirety of the physical memory of a system. MKTME builds on TME and
+ adds support for multiple encryption keys.
+
+
+ For more details on MKTME feature see:
+ MKTME spec
+
+
+
+ keys_supported
+ - When mktme is enabled, keys_supported information is avaiable
+
+