Guard against non-secure partitions and files on disk

You have two options for sending your encrypted boot image to the cloud provider.

• Option 1: If you send the boot image that you created in Securing the guest separately from the volume image, destroy the boot partition before you create the volume image.
  For example, if /dev/vda1 is the boot partition, use:

  # shred /dev/vda1

  For information about how to boot from a separate boot image file, see Step 3 "Configure for direct kernel boot" in Starting the secure virtual server.
• Option 2: If you send the boot image on the unencrypted boot partition, the cloud provider can read from and write to this unencrypted partition.
  To avoid security issues, ensure that:
  1. No sensitive content remains on the unencrypted partition. Use, for example, sfill to wipe any free space on the disk to ensure that no traces of confidential data remain. See also Securely delete sensitive files from the unencrypted boot partition.
  2. The unencrypted partition is not mounted by the secure guest.
     Edit /etc/fstab and remove /boot (or on SUSE Enterprise Linux® Server, /boot/zipl).

     With no volume mounted at /boot, or /boot/zipl, potentially non-secure new kernels or kernel updates are written to the /boot, or /boot/zipl, sub-directories of the root file system, which is backed by an encrypted volume. Because you cannot boot from an encrypted volume, these untrusted kernels are not a threat.