3:38 a.m.
On Wed, May 01, 2019 at 14:41:57 -0700, Larkins Carvalho wrote:
From: llcarval <larkins.l.carvalho(a)intel.com>
Total Memory Encryption (TME) – 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
<feature>
...
<mktme supported='yes'>
<keys_supported> </keys_supported>
</mktme>
</feature>
2. Management tool requests to start a guest calling virCreateXML(). The xml would
include
<launchsecurity type='mktme'>
<id>m0</id>
<key_type>user</key_type>
<key>samplekey</key>
<encryption_algorithm>aes-xts-128</encryption_algorithm>
</launchSecurity>
3. Libvirt makes system call with the provided information to generate a key 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=m0 \
-object mktme-guest,id=m0,handle=${serial}
Intel MKTME spec:
https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-To...
WIP: Qemu and KVM patch to support Intel MKTME are in the process of development and
community approval.
The purpose of this initial review is to get on par with libvirt development 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 +++++++++++++++++
Please be advised that we will not accept everything stuffed into one
commit. Please split up this patch into logical units as it's usual
(look at other series) and also make sure that it's possible to compile
the tree including running make check and make syntax check after every
single commit.