libvirt: AMD SEV-ES support
NOTE: This will be submitted for reference and early discussions. This should be resubmitted to 2024.2 once spec proposal is open. blueprint: amd-sev-es-libvirt-support Change-Id: Ia18d836d77133b06439cc5f5471496d4ea6f6910
This commit is contained in:
parent
f0ffcb6ddf
commit
51f6e249fd
311
specs/2024.1/approved/amd-sev-es-libvirt-support.rst
Normal file
311
specs/2024.1/approved/amd-sev-es-libvirt-support.rst
Normal file
@ -0,0 +1,311 @@
|
|||||||
|
..
|
||||||
|
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 compatible 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 different from maximum
|
||||||
|
number of SEV guests.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
SEV and SEV-ES have separate limits of guest numbers, because ASIDs are
|
||||||
|
allocated for ES guests and non-ES guests exclusively, from the total
|
||||||
|
ASIDs available. Minimum ASID for SEV (non-ES) guests, which is
|
||||||
|
effectively same as maxumum ASID for ES guests, should be configured in
|
||||||
|
BIOS (or UEFI) to use SEV-ES. SEV-SNP uses the same ASID pool for ES,
|
||||||
|
unless cyphertext hiding is requested, is expected to able to use the same
|
||||||
|
v2 class by default.
|
||||||
|
|
||||||
|
- 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``.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
When this is extended to SEV-SNP, a combination of
|
||||||
|
resources:MEM_ENCRYPTION_CONTEXT_V2=1 and HW_CPU_AMD_SEV_SNP trait would
|
||||||
|
be used to indicate that a user requests SEV-SNP.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
- AMD EPYC 7xx2 (Rome) or later
|
||||||
|
|
||||||
|
- Set minimum ASID for SEV (non-ES) guests 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
|
Loading…
Reference in New Issue
Block a user