Preparing the boot image

Prepare a KVM guest for running in IBM Secure Execution mode. The guest that you create for running in a cloud must be adequately secured. Consider all access paths to it, including console logins.

1. Install a standard Linux instance. This example uses an Ubuntu 20.04 instance.
   Accept the installer defaults, unless you want to use fixed IP addresses.
   In the package selection step, select OpenSSH to use SSH and SCP connections to your guest.
   Encrypt your root filesystem. See Important note in Preparing the boot image.
2. Prepare a kernel parameter file.
   Create a new file, called, for example parmfile.

   1. The boot configuration (zipl.conf, BLS entries, or grub.cfg) of the installed standard Linux instance contains a line that specifies the root device. Copy these parameters to the parmfile.
      Tip: Read /proc/cmdline to find out which parameters were used to start your Linux instance.
   2. Define a bounce buffer with the swiotlb= parameter.
      Tip: Use a setting of 262144 for best results.
      Add the swiotlb= parameter to the parameter line.
   Your parmfile might, for example, look like:

   root=UUID=694fd9a4-4180-4c47-92e0-7aa4fe06d370 crashkernel=196M swiotlb=262144

   You can use virt-install to set up a Linux instance:

   1. Download the Ubuntu 20.04 CD-ROM image for IBM Z from http://cdimage.ubuntu.com/releases/focal/release/ into the directory /var/lib/libvirt/images
   2. Use a command like the following to set up secguest1 as an Ubuntu 20.04 instance with 4 GB of memory on an 8 GB QCOW2 disk with the default libvirt network:

      # virt-install --name secguest1 --memory 4096 --disk size=8 \
      --cdrom /var/lib/libvirt/images/ubuntu-<version>-live-server-s390x.iso

   Obtain the domain configuration-XML with the following command:

   virsh dumpxml secguest1 > secguest1.xml

   Remember to modify the XML to allow bounce buffers with iommu=on.
3. Mount the directories where the kernel, the initial RAM file system, and the kernel parameter file are located.
4. Disable root login on consoles.
   • Enforce secure remote login only.
     • Set up SSHD and SSH keys.
     • Disable login on consoles by disabling serial and virtual TTYs. For example, using systemd:

       # cat /etc/systemd/system/serial-getty@.service.d/disable.conf
       [Unit]
       ConditionKernelCommandLine=allowlocallogin
       # cat /etc/systemd/system/autovt@.service.d/disable.conf
       [Unit]
       ConditionKernelCommandLine=allowlocallogin

       The example shows how a disable.conf file defines a kernel parameter, allowlocallogin. With this configuration file, local logins are possible if the Linux instance is started with the allowlocallogin kernel parameter in the parameter file that is used to build the image. Use this technique, for example, for debugging.
     • Remove information leaks on the kernel console by setting loglevel=0 and systemd.show_status=0.
     • On Ubuntu Server: Edit the /etc/securetty to prevent console logins. Remove the contents of the file to not allow any logins. This prevents any logins from the hypervisor environment.
       For example, to remove all content in /etc/securetty, issue the following command:

       # echo > /etc/securetty

   • Disable the debug shell in initramfs by setting the panic= parameter.
   • Disable debug, emergency, and rescue shells. For example, using systemd, mask the corresponding services:

     # systemctl mask emergency.service
     # systemctl mask emergency.target
     
     # systemctl mask rescue.service
     # systemctl mask rescue.target

5. Avoid using the virtio-rng.
   To defend against a possible malicious random-number generator on the host, exclude the virtio-rng. You can do this, for example, by using a module configuration file, /etc/modprobe.d/virtio-rng.conf , with the following content:

   blacklist virtio-rng

6. Your guest runs in the context of a virtual server. The virtual server defines the virtual hardware. IBM Secure Execution has configuration requirements on the virtual server. See Starting the secure virtual server.

   Configure the QCOW2 image according to your needs. Pre-allocate it to optimize performance, or use a sparse setting to minimize size.

   For more information about the domain configuration-XML and how to configure virtual servers, see KVM Virtual Server Management, SC34-2752.

   Tip: Use virt-manager to work with the XML.