libvirt: AMD SEV-ES support

Still WIP. Should be resubmitted to 2024.2 once spec proposal is open.

Change-Id: Ia18d836d77133b06439cc5f5471496d4ea6f6910
This commit is contained in:
Takashi Kajinami 2024-02-05 14:43:16 +09:00
parent f0ffcb6ddf
commit b2d4f6544f

View File

@ -0,0 +1,300 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=======================================================================
libvirt driver launching instances with memory encryption by AMD SEV-ES
=======================================================================
https://blueprints.launchpad.net/nova/+spec/amd-sev-es-libvirt-support
This spec proposes work required in order to extend the existing libvirt driver
feature to launch AMD SEV-encrypted instances, to support also using AMD
SEV-ES, which is the extended version of AMD SEV, as memory encryption
mechanism.
Problem description
===================
Current libvirt driver supports launching instances with memory encryption by
`AMD's SEV (Secure Encrypted Virtualization) technology
<https://developer.amd.com/sev/>`_. However the current implementation supports
only AMD SEV, and does not support new versions. For exmaple SEV-ES also
encrypts all CPU register contents when a VM stops running, to achieve more
complete protection of VM data, but users can't leverage these features because
of this limitation.
.. note::
At the time or writing AMD already released CPUs which supports SEV-SNP, but
the required hypervisor features to use SEV-SNP are not yet merged into
the underlying components(kernel, QEMU, libvirt and ovmf). So in this spec
we focus on SEV-ES. We attempt to keep the proposal as much compatiblre with
SEV-SNP as possible, based on the implementations published by AMD.
Use Cases
---------
#. As a cloud administrator, in order that my users can have more confidence
in the security of their running instances, I want to provide a flavor
containing the `required trait extra spec
<https://docs.openstack.org/nova/latest/user/flavors.html#extra-specs-required-traits>`_
which will allow users booting instances with that flavor to ensure
that their instances run on an SEV-ES-capable compute host with SEV-ES
encryption, instead of SEV encryption, enabled.
#. As a cloud user, in order to reduce data leakage risks further, I want to
be able to boot VM instances with SEV-ES functionality, instead of SEV
functionality, enabled.
Proposed change
===============
We propose extending the existing implementation to support launching instances
with SEV functionality.
- Add detection of host SEV-ES capabilities, which checks the following items.
- The presence of the following XML in the response from a libvirt
`virConnectGetDomainCapabilities()
<https://libvirt.org/html/libvirt-libvirt-domain.html#virConnectGetDomainCapabilities>`_
API call `indicates that both QEMU and the AMD Secure Processor
(AMD-SP) support SEV functionality
<https://libvirt.org/git/?p=libvirt.git;a=commit;h=6688393c6b222b5d7cba238f21d55134611ede9c>`_::
<domainCapabilities>
...
<features>
...
<sev supported='yes'/>
...
</sev>
</features>
</domainCapabilities>
- ``/sys/module/kvm_amd/parameters/sev_es`` should have the value ``Y``
to indicate that the kernel has SEV capabilities enabled. This
should be readable by any user (i.e. even non-root).
- Implement a new ``MEM_ENCRYPTION_CONTEXT_V2`` `resource class
<https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html>`_
to represent the number of guests with SEV-ES enabled which a compute host
can run concurrently. A separate resource class is required because maximum
number of SEV-ES guests a compute host can accept is separate from maximum
number of SEV guests.
.. note::
SEV and SEV-ES have separate limits of guest numbers, because SEV-ES
requires SEV ASID while SEV does not. Maximum ASID should be configured in
BIOS (or UEFI) to use SEV-ES. SEV-SNP requires ASID, so is expected to be
able to use the same v2 class.
- Add the new ``HW_CPU_AMD_SEV_ES`` trait to os-traits.
- Make the libvirt driver `update the ProviderTree object
<https://docs.openstack.org/nova/latest/reference/update-provider-tree.html>`_
with the correct inventory for the new ``MEM_ENCRYPTION_CONTEXT_V2``
resource class.
- Change the libvirt driver to include extra XML in the guest's domain
definition when ``resources:MEM_ENCRYPTION_CONTEXT_V2=1`` is present in
the flavor extra specs. The extra XML is mostly similar to the one used in
SEV, but its guest policy field needs the SEV-ES bit (bit 2) enabled.
- Add support for a new ``hw:mem_encryption_mechanism`` parameter in flavor
extra specs, and a new ``hw_mem_encryption_mecnahism`` image property. When
either of these is set to ``amd-sev-es`` along with the parameter/propery to
enable memory encryption, it would be internally translated to
``resources:MEM_ENCRYPTION_CONTEXT_V2=1`` which would
be added to the flavor extra specs in the ``RequestSpec`` object.
if these new mechanism parameter/property is absent or set to ``amd-sev``
then it would be translated to ``resources:MEM_ENCRYPTION_CONTEXT=1``.
Alternatives
------------
None
Data model impact
-----------------
A new resource class will be used to inventory slots for SEV-ES guests on
SEV-ES-capable compute hosts.
A new configuration option will be used (at least in the short term)
to specify the maximum number of SEV-ES guests runnable on each compute
host. This overrides the maximum number determined using the number exposed by
libvirt API, in case the given limit is lower than the actual limit.
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
The end user will harness SEV-ES through the existing mechanisms of
resources in flavor extra specs and image properties.
Performance Impact
------------------
No performance impact on nova is anticipated.
Perfomance impact for the other parts are same as the existing SEV support
feature.
Other deployer impact
---------------------
In order for users to be able to use SEV-ES, the operator will need to
perform the following steps:
- Deploy SEV-ES-capable hardware as nova compute hosts.
- Set maximum ASID in BIOS (or UEFI) to a value greater than 0.
- Ensure that they have an appropriately configured software stack, so
that the various layers are all SEV-ES ready:
- kernel >= 4.16
- QEMU >= 6.1.0
- libvirt >= 4.5
- ovmf >= commit 7f0b28415cb4 2020-08-12
Finally, a cloud administrator will need to define SEV-ES-enabled flavors
as described above, unless it is sufficient for users to define
SEV-ES-enabled images.
Developer impact
----------------
None
Upgrade impact
--------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
kajinamit (irc: tkajinam)
Other contributors:
None
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Consider creating an ordering of patches, that allows gradually merging
instead of the need to merge them all at once. For example if you are
introducing a feature that requires implementation changes in multiple VM
lifecycle operations then first add a step that rejects all the not yet
supported actions with a HTTP 400 Bad Request. The error should explain that
the <operation> is not supported with <feature> at this time. Then gradually
remove the limitation as you progress with the implementation. This way we can
merge your changes gradually and regardless when the feature freeze hit we can
be sure that the system is consistent.
Future work
-----------
None
Dependencies
============
* Special hardware which supports SEV-ES for development, testing, and CI.
* Recent versions of the hypervisor software stack which all support
SEV-ES, as detailed in `Other deployer impact`_ above.
Testing
=======
The ``fakelibvirt`` test driver will need adaptation to emulate
SEV-ES-capable hardware.
Corresponding unit/functional tests will need to be extended or added
to cover:
- detection of SEV-ES-capable hardware and software, e.g. perhaps as an
extension of
``nova.tests.functional.libvirt.test_report_cpu_traits.LibvirtReportTraitsTests``
- the use of a trait to include extra SEV-specific libvirt domain XML
configuration, e.g. within
``nova.tests.unit.virt.libvirt.test_config``
Documentation Impact
====================
- Update the entry in `the Feature Support Matrix
<https://docs.openstack.org/nova/latest/user/support-matrix.html>`_,
to explain now AMD SEV-ES is supported in addition to AMD SEV.
- Update the existing `AMD SEV
<https://docs.openstack.org/nova/latest/admin/sev.html>`_ guide to include
information about SEV-ES>
Other non-nova documentation should be updated too:
- The `documentation for os-traits
<https://docs.openstack.org/os-traits/latest/>`_ should be extended
where appropriate.
References
==========
- `AMD SEV landing page <https://developer.amd.com/sev>`_
- `AMD SEV-KM API Specification
<https://developer.amd.com/wp-content/resources/55766.PDF>`_
- `AMD SEV github repository containing examples and tools
<https://github.com/AMDESE/AMDSEV/>`_
- `Slides from the 2017 Linux Security Summit describing SEV and
preliminary performance results
<http://events17.linuxfoundation.org/sites/events/files/slides/AMD%20SEV-ES.pdf>`_
- `libvirt's SEV options <https://libvirt.org/formatdomain.html#sev>`_
History
=======
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - 2024.2 Dalmetian
- Introduced