Bug 1913699 - [QE][OSP 16.2] A couple of suggestions for the AMD SEV section of the docs
Summary: [QE][OSP 16.2] A couple of suggestions for the AMD SEV section of the docs
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 16.2 (Train)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Irina
QA Contact: Archit Modi
URL:
Whiteboard: docs-accepted
Depends On: 1794216 1833442 1959360
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-07 12:08 UTC by Kashyap Chamarthy
Modified: 2021-07-15 14:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-15 14:29:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kashyap Chamarthy 2021-01-07 12:08:17 UTC
Based on discussion with a libvirt and QEMU devs, I suggest a few
changes (also note the TODOs below) to the SEV docs in OSP:

(1) We should specify the Tech Preview is possible from AMD 'Rome' 
    generation of hardware onwards.

    Some background: There are three kinds of SEV, each available in a
    different hardware, and each providing a different level of 
    protection (I'm skipping some details here, but this is the gist):

      - SEV: Just the memory of a VM is encrypted.  Available since AMD
        "Epyc".

      - SEV-ES: encrypted state.  Along with memory, the CPU registers
        are also encrypted.  Available since AMD "Rome".

      - SEV-SNP: secure nested paging.  Along with memory and CPU
        registers, it also protects against "replay attacks"; and provides
        other advanced features.  Should be available in future editions
        of AMD hardware.

    Although, 'SEV' is technically available from "Epyc" generation 
    onwards, the lower level Red Hat virt components could only be
    stabilized from "Rome" onwards.  Hence the reason to add the note.

(2) I learnt that this sentence in the "Limitations of SEV-encrypted
    instances" is now out-of-date:

        "You cannot use virtio-blk as the boot disk of SEV-encrypted
        instances."

    TODO: Figure out which specific version RHEL kernel has this fix,
          and mention it in the docs.

(3) This sentence in the "Limitations of SEV-encrypted
    instances" isn't useful by itself without also telling *how* to 
    check if a guest OS is capable of SEV (before launching that guest 
    OS with SEV configuration):

        "The operating system running in an encrypted instance must 
        contain SEV support."

    TODO: Find out if there are any RHEL docs that has pointers about 
          how to verify this.

(4) Once SEV support is determined in libvirt, QEMU, and kernel), and an
    instance is launched with SEV capability, it can be verified from
    *within* the guest, by running:

        $> dmesg | grep -i sev
        AMD Secure Encrypted Virtualization (SEV) active
        
    We should add a note about this.
        

[+] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/instances_and_images_guide/memory-encryption-for-instances


Note You need to log in before you can comment on or make changes to this bug.