[Workload]: encryption

Workload Name

encryption

Workload Description

Cryptographic operations workload that runs sustained AES, SHA, RSA, and ECDSA operations using OpenSSL's speed benchmark and optionally exercises vTPM and SEV-ES/SEV-SNP confidential computing features. Produces continuous CPU-bound crypto throughput (MB/s for symmetric ciphers, operations/sec for asymmetric), crypto instruction utilization (AES-NI, SHA-NI), and — when hardware is available — attestation and sealed-key signals from confidential computing features.

This workload targets security, compliance, and confidential computing partners. As SEV-ES and SEV-SNP support matures in OpenShift Virtualization (AMD EPYC) and TDX support arrives (Intel Xeon), partners building confidential computing, key management, and compliance products need a reproducible workload that exercises the VM's cryptographic capabilities under sustained load. Even without confidential computing hardware, the crypto throughput signal is valuable for partners validating encryption-at-rest, TLS termination, and hardware security module (HSM) integration.

Tooling and Packages

• Tool: openssl speed (built into every Linux distribution — zero additional packages)
• RPM packages: openssl (pre-installed on all base images), optionally tpm2-tools for vTPM operations
• systemd service command: openssl speed -evp aes-256-gcm -seconds 0 (run AES-256-GCM indefinitely)
  • -evp: use the EVP (high-level) API, which enables hardware acceleration (AES-NI)
  • -seconds 0: run each algorithm indefinitely (default runs 3 seconds per algorithm)
• Extended mode (multi-algorithm loop):

  while true; do
    openssl speed -evp aes-256-gcm -seconds 60
    openssl speed -evp sha256 -seconds 60
    openssl speed rsa2048 -seconds 60
    openssl speed ecdsap256 -seconds 60
  done
  

• Configurable parameters:
  • crypto-algorithms: comma-separated list (default: aes-256-gcm,sha256,rsa2048,ecdsap256)
  • crypto-seconds-per-algo: seconds to run each algorithm before rotating (default: 60)
  • crypto-multi: number of parallel threads (default: number of CPUs)
  • crypto-tpm: enable vTPM exercise loop (default: false, requires vTPM device)

VM Count Model

Single VM (like cpu, memory, disk)

Required Resources

• Persistent storage (DataVolume)
• Kubernetes Service (for inter-VM communication)
• Kubernetes Secret (for credentials or config)
• Additional CPU/memory beyond defaults
• GPU or special device passthrough

For basic crypto stress, no special resources needed — OpenSSL is pre-installed and uses CPU only. For vTPM testing, the VM spec must include spec.domain.devices.tpm: {} to attach a virtual TPM 2.0 device. For SEV-ES/SEV-SNP, the VM spec requires spec.domain.launchSecurity configuration and AMD EPYC hardware with SEV enabled.

Cloud-Init Details

packages:
  - openssl
  - tpm2-tools
write_files:
  - path: /usr/local/bin/virtwork-encryption.sh
    permissions: '0755'
    content: |
      #!/bin/bash
      set -euo pipefail
      ALGORITHMS="${CRYPTO_ALGORITHMS:-aes-256-gcm,sha256,rsa2048,ecdsap256}"
      SECONDS_PER="${CRYPTO_SECONDS_PER_ALGO:-60}"
      MULTI="${CRYPTO_MULTI:-$(nproc)}"
      TPM_ENABLED="${CRYPTO_TPM:-false}"

      IFS=',' read -ra ALGO_LIST <<< "$ALGORITHMS"

      # Optional: exercise vTPM if available and enabled
      if [ "$TPM_ENABLED" = "true" ] && [ -c /dev/tpmrm0 ]; then
        echo "vTPM detected, starting TPM exercise loop in background"
        (
          while true; do
            # Generate random key, seal to TPM, unseal, verify
            tpm2_getrandom 32 > /tmp/tpm_random.bin
            tpm2_createprimary -C o -c /tmp/primary.ctx 2>/dev/null
            tpm2_create -C /tmp/primary.ctx -u /tmp/seal.pub -r /tmp/seal.priv \
              -i /tmp/tpm_random.bin 2>/dev/null
            tpm2_load -C /tmp/primary.ctx -u /tmp/seal.pub -r /tmp/seal.priv \
              -c /tmp/seal.ctx 2>/dev/null
            tpm2_unseal -c /tmp/seal.ctx -o /tmp/unseal.bin 2>/dev/null
            diff /tmp/tpm_random.bin /tmp/unseal.bin > /dev/null && \
              echo "TPM seal/unseal: OK" || echo "TPM seal/unseal: MISMATCH"
            rm -f /tmp/primary.ctx /tmp/seal.* /tmp/tpm_random.bin /tmp/unseal.bin
            sleep 5
          done
        ) &
      fi

      # Main crypto loop
      while true; do
        for algo in "${ALGO_LIST[@]}"; do
          echo "=== Running: $algo for ${SECONDS_PER}s with $MULTI threads ==="
          case "$algo" in
            rsa*|ecdsa*|eddsa*)
              openssl speed -multi "$MULTI" -seconds "$SECONDS_PER" "$algo"
              ;;
            *)
              openssl speed -multi "$MULTI" -evp "$algo" -seconds "$SECONDS_PER"
              ;;
          esac
        done
      done
  - path: /etc/systemd/system/virtwork-encryption.service
    content: |
      [Unit]
      Description=Virtwork encryption/crypto stress workload
      After=multi-user.target
      [Service]
      Type=simple
      Environment=CRYPTO_ALGORITHMS=aes-256-gcm,sha256,rsa2048,ecdsap256
      Environment=CRYPTO_SECONDS_PER_ALGO=60
      Environment=CRYPTO_TPM=false
      ExecStart=/usr/local/bin/virtwork-encryption.sh
      Restart=always
      RestartSec=5
      [Install]
      WantedBy=multi-user.target
runcmd:
  - systemctl enable --now virtwork-encryption.service

Use Case

• Confidential computing partners (AMD, Intel, Edgeless Systems, Fortanix, Anjuna): As SEV-ES/SEV-SNP (AMD) and TDX (Intel) support matures in OpenShift Virtualization, partners building confidential VM platforms need a workload that exercises crypto operations inside a confidential VM. The workload validates that hardware-accelerated crypto (AES-NI inside SEV) performs at expected throughput and that attestation flows work correctly.
• Key management / HSM partners (Thales, Entrust, HashiCorp Vault): Partners whose products manage encryption keys for VMs need sustained crypto operations to validate key lifecycle — rotation, access logging, and performance impact of key management overhead. The crypto throughput numbers provide a baseline that should remain stable when the partner's KMS is integrated.
• Security/Compliance partners (CrowdStrike, Aqua, Sysdig Secure): Security products that monitor for crypto-mining or anomalous CPU usage need to distinguish legitimate crypto workloads from malicious ones. This workload produces a known crypto pattern that security products should classify correctly — a false positive (flagging virtwork's OpenSSL as crypto-mining) reveals a product issue.
• Encryption-at-rest validation: Storage partners implementing encryption-at-rest need to understand the CPU overhead of crypto operations. Running this workload alongside disk (fio) quantifies the throughput impact of software vs hardware crypto on VM I/O performance.
• TLS termination partners (F5, HAProxy, Nginx Plus): Partners terminating TLS at load balancers or service meshes need to understand the crypto capabilities of the VM fleet. OpenSSL speed provides the raw throughput numbers (RSA handshakes/sec, AES throughput) that determine how many TLS connections a VM can handle.
• vTPM validation: KubeVirt supports virtual TPM 2.0 devices. The optional vTPM exercise loop (seal/unseal cycle) validates that the vTPM device is functional, that key operations work correctly, and that the TPM state persists across VM reboots — critical for partners building measured boot or secure key storage on OpenShift VMs.

Additional Context

• Zero dependencies for basic mode: OpenSSL is pre-installed on every Linux base image. The basic crypto stress workload (no vTPM, no SEV) requires zero additional packages — the simplest possible cloud-init. tpm2-tools is only needed if crypto-tpm=true.
• Hardware acceleration detection: OpenSSL automatically uses AES-NI and SHA-NI instructions when available. The output includes whether hardware acceleration is active. This is useful for validating that the VM correctly exposes the host's crypto instructions through KubeVirt's CPU model passthrough (spec.domain.cpu.model: host-passthrough).
• Output format: openssl speed outputs throughput in standardized format:

  type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
  aes-256-gcm     876543.21k  2345678.90k  4567890.12k  5678901.23k  6123456.78k  6234567.89k
  

  These numbers are directly comparable across runs, VMs, and platforms — partners use them for performance regression testing.
• SEV-ES/SEV-SNP configuration: For confidential computing testing, the VM spec requires:

  spec:
    domain:
      launchSecurity:
        sev:
          attestation: {}
  

  This is an advanced configuration that requires AMD EPYC hardware and cluster-level SEV enablement. Document as an optional enhancement, not a requirement for the basic workload.
• Algorithm selection rationale:
  • aes-256-gcm: the standard symmetric cipher for TLS 1.3 and encryption-at-rest — the most relevant for partner validation
  • sha256: used in certificate verification, integrity checks, and blockchain — high-frequency operation
  • rsa2048: TLS handshake (key exchange) — measures handshakes/sec
  • ecdsap256: modern TLS certificate signing — measures signatures/sec
    This covers the four major crypto operations partners care about: bulk encryption, hashing, key exchange, and signing.
• Multi-threaded scaling: The -multi flag spawns parallel OpenSSL processes. At -multi $(nproc), all VM CPUs are saturated with crypto operations. This is useful for measuring per-core crypto throughput and validating that CPU pinning (from the Cookbook's performance tuning) delivers consistent per-core performance.

Start by locating the repository's existing workload definitions and cloud-init entry points, then compare their structure with /usr/local/bin/virtwork-encryption.sh and /etc/systemd/system/virtwork-encryption.service described here. Verify the OpenSSL speed loop, configurable algorithms and thread count, and optional vTPM or confidential-computing settings. Done means the workload can run continuously in a VM and report the specified crypto throughput signals.