Generic SEL guests

Edit online

With the introduction of IBM® z17 ™ and retrievable secrets, you can now create generic Secure Execution Linux (SEL) guests. The boot image of a generic SEL guest is not encrypted, but the guest still benefits from isolation and integrity protections enforced by IBM Secure Execution and the ultravisor.

This topic introduces the concept of generic SEL guests, explains their purpose, and outlines how retrievable secrets allow such guests to be securely personalized.

A generic SEL guest is a Secure Execution Linux guest that:
  • Runs in the IBM Secure Execution environment, benefiting from workload isolation enforced by the ultravisor. Even without boot image encryption, the ultravisor enforces separation between SEL guests and the hypervisor.
  • Uses an unencrypted image as its basis. The base operating system image remains readable.
  • Can access sensitive configuration data through retrievable secrets, ensuring tenant-specific personalization. Through add-secret requests, a guest can be customized with sensitive material at boot time.

Generic SEL guests reduces complexity for Independent Software Vendors (ISVs) and infrastructure providers, while still supporting tenant-specific confidentiality for critical keys and credentials.

Uses for generic SEL guests include:
  • ISV-prepared generic (SEL hardened) guest images
  • Generic Kata guests for confidential containers
With plaintext images, either the infrastructure provider or the tenant can build the SEL image choosing the target host keys for the planned deployments.

Requirements

To create a generic SEL image, several requirements must be met.

Preparation for add-secret requests
The image must be designed to read add-secret requests very early in the boot process. This typically involves mounting an untrusted, unencrypted file system that provides the add-secret request list.
Integrity of the add-secret request list
The add-secret request list itself must be protected against tampering:
  • Completeness: ensuring no required add-secret requests are missing.
  • Whitelisting: ensuring no additional, unwanted add-secret requests are introduced.
Note: The ultravisor checks the integrity of each add-secret request when submitted, but the guest must still verify the correctness of the overall add-secret request set.
Successful submission to the ultravisor
Each add-secret request must be passed to the ultravisor for processing. The ultravisor validates the requests and makes corresponding retrievable secrets available to the guest.
Use of retrievable secrets
Once retrieved, the secrets must be applied during system initialization. This enables the guest to unlock, configure, and personalize itself securely. For more details about the use of retrievable secrets, see Creating and retrieving retrievable secrets.
Common retrievable secrets used in generic SEL guests include:
  • Root file-system keys, such as a LUKS passphrase or data encryption key.
  • Service keys. These are private keys for sshd or TLS servers.
  • Administrative credentials: Including initial passwords and SSH certificates.
Use a customer communication key
Another important secret to add is the customer communication key (CCK). This key ensures that dumps are readable only by the tenant. Dumps must be enabled during SEL image creation by using the pvimg create --enable-dump option, with either the --cck or the --enable-cck-update options.

The --enable-cck-update option enables the tenant to change the CCK at SEL guest runtime. For more details about creating a SEL image, see pvimg - Create and inspect IBM SEL images.

Overview of setup of a generic guest

Setting up a generic guest includes preparing a base image, preparing secrets, and personalizing the guest. The following steps are an overview without details presented for planning purposes.

  1. Prepare the base image.

    You need to build an unencrypted Linux image and integrate logic to process add-secret requests at early boot. To build an unencrypted image, use the pvimg create command with the --disable-image-encryption option. For details about the command, see pvimg create - Generate an IBM SEL image.

  2. Define a personalization policy.

    You need to specify which secrets the guest requires (for example, a root file-system key, or an SSH key) and generate an add-secret request list according to this policy.

  3. Provision the SEL guest image and the secrets, in the form of add-secret requests, to the hypervisor.

    Infrastructure provider or tenant adds retrievable secrets to the hypervisor. The add-secret request list is placed on the guest’s accessible filesystem.

  4. Boot the guest.

    When booting, the guest reads the add-secret request list, submits each add-secret request to the UV, retrieves and applies secrets. This, for example, unlocks the root file system, configures the SSH, and sets administrator credentials.

  5. Personalize the guest.

    The tenant verifies successful secret retrieval. Tenant-specific identity and configuration must be established.