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
parent
f0ffcb6ddf
commit
b2d4f6544f
300
specs/2024.1/approved/amd-sev-es-libvirt-support.rst
Normal file
300
specs/2024.1/approved/amd-sev-es-libvirt-support.rst
Normal 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
|
||||
Loading…
Reference in New Issue
Block a user