Chapter 19. Securing virtual machines As an administrator of a RHEL 9 system with virtual machines (VMs), ensuring that your VMs are as secure as possible significantly lowers the risk of your guest and host OSs being infected by malicious software. The following sections outline the mechanics of securing VMs on a RHEL 9 host and provides a list of methods to increase the security of your VMs. 19.1. How security works in virtual machines When using virtual machines (VMs), multiple operating systems can be housed within a single host machine. These systems are connected with the host through the hypervisor, and usually also through a virtual network. As a consequence, each VM can be used as a vector for attacking the host with malicious software, and the host can be used as a vector for attacking any of the VMs. Figure 19.1. A potential malware attack vector on a virtualization host Because the hypervisor uses the host kernel to manage VMs, services running on the VM's operating system are frequently used for injecting malicious code into the host system. However, you can protect your system against such security threats by using a number of security features on your host and your guest systems. These features, such as SELinux or QEMU sandboxing, provide various measures that make it more difficult for malicious code to attack the hypervisor and transfer between your host and your VMs. Figure 19.2. Prevented malware attacks on a virtualization host Many of the features that RHEL 9 provides for VM security are always active and do not have to be enabled or configured. For details, see Automatic features for virtual machine security . In addition, you can adhere to a variety of best practices to minimize the vulnerability of your VMs and your hypervisor. For more information, see Best practices for securing virtual machines . 19.2. Best practices for securing virtual machines Following the instructions below significantly decreases the risk of your virtual machines being infected with malicious code and used as attack vectors to infect your host system. On the guest side: Secure the virtual machine as if it was a physical machine. The specific methods available to enhance security depend on the guest OS. If your VM is running RHEL 9, see Securing Red Hat Enterprise Linux 9 for detailed instructions on improving the security of your guest system. On the host side: When managing VMs remotely, use cryptographic utilities such as SSH and network protocols such as SSL for connecting to the VMs. Ensure SELinux is in Enforcing mode: If SELinux is disabled or in Permissive mode, see the Using SELinux document for instructions on activating Enforcing mode. Note SELinux Enforcing mode also enables the sVirt RHEL 9 feature. This is a set of specialized SELinux booleans for virtualization, which can be manually adjusted for fine-grained VM security management. Use VMs with SecureBoot : SecureBoot is a feature that ensures that your VM is running a cryptographically signed OS. This prevents VMs whose OS has been altered by a malware attack from booting. SecureBoot can only be applied when installing a Linux VM that uses OVMF firmware on an AMD64 or Intel 64 host. For instructions, see Creating a SecureBoot virtual machine . Do not use qemu-* commands, such as qemu-kvm . QEMU is an essential component of the virtualization architecture in RHEL 9, but it is difficult to manage manually, and improper QEMU configurations may cause security vulnerabilities. Therefore, using most qemu-* commands is not supported by Red Hat. Instead, use libvirt utilities, such as virsh , virt-install , and virt-xml , as these orchestrate QEMU according to the best practices. Note, however, that the qemu-img utility is supported for management of virtual disk images . Additional resources SELinux booleans for virtualization in RHEL 19.3. Automatic features for virtual machine security In addition to manual means of improving the security of your virtual machines listed in Best practices for securing virtual machines , a number of security features are provided by the libvirt software suite and are automatically enabled when using virtualization in RHEL 9. These include: System and session connections To access all the available utilities for virtual machine management in RHEL 9, you need to use the system connection of libvirt ( qemu:///system ). To do so, you must have root privileges on the system or be a part of the libvirt user group. Non-root users that are not in the libvirt group can only access a session connection of libvirt ( qemu:///session ), which has to respect the access rights of the local user when accessing resources. For example, using the session connection, you cannot detect or access VMs created in the system connection or by other users. Also, available VM networking configuration options are significantly limited. Note The RHEL 9 documentation assumes you have system connection privileges. Virtual machine separation Individual VMs run as isolated processes on the host, and rely on security enforced by the host kernel. Therefore, a VM cannot read or access the memory or storage of other VMs on the same host. QEMU sandboxing A feature that prevents QEMU code from executing system calls that can compromise the security of the host. Kernel Address Space Randomization (KASLR) Enables randomizing the physical and virtual addresses at which the kernel image is decompressed. Thus, KASLR prevents guest security exploits based on the location of kernel objects. 19.4. Creating a SecureBoot virtual machine You can create a Linux virtual machine (VM) that uses the SecureBoot feature, which ensures that your VM is running a cryptographically signed OS. This can be useful if the guest OS of a VM has been altered by malware. In such a scenario, SecureBoot prevents the VM from booting, which stops the potential spread of the malware to your host machine. Prerequisites The VM is the Q35 machine type. Your host system uses the AMD64 or Intel 64 architecture. The edk2-OVMF packages is installed: An operating system (OS) installation source is available locally or on a network. This can be one of the following formats: An ISO image of an installation medium A disk image of an existing VM installation Warning Installing from a host CD-ROM or DVD-ROM device is not possible in RHEL 9. If you select a CD-ROM or DVD-ROM as the installation source when using any VM installation method available in RHEL 9, the installation will fail. For more information, see the Red Hat Knowledgebase solution RHEL 7 or higher can't install guest OS from CD/DVD-ROM . Optional: A Kickstart file can be provided for faster and easier configuration of the installation. Procedure Use the virt-install command to create a VM as detailed in Creating virtual machines by using the command line . For the --boot option, use the uefi,nvram_template=/usr/share/OVMF/OVMF_VARS.secboot.fd value. This uses the OVMF_VARS.secboot.fd and OVMF_CODE.secboot.fd files as templates for the VM's non-volatile RAM (NVRAM) settings, which enables the SecureBoot feature. For example: Follow the OS installation procedure according to the instructions on the screen. Verification After the guest OS is installed, access the VM's command line by opening the terminal in the graphical guest console or connecting to the guest OS using SSH . To confirm that SecureBoot has been enabled on the VM, use the mokutil --sb-state command: Additional resources Manually installing Red Hat Enterprise Linux 19.5. Limiting what actions are available to virtual machine users In some cases, actions that users of virtual machines (VMs) hosted on RHEL 9 can perform by default may pose a security risk. If that is the case, you can limit the actions available to VM users by configuring the libvirt daemons to use the polkit policy toolkit on the host machine. Procedure Optional: Ensure your system's polkit control policies related to libvirt are set up according to your preferences. Find all libvirt-related files in the /usr/share/polkit-1/actions/ and /usr/share/polkit-1/rules.d/ directories. Open the files and review the rule settings. For information about reading the syntax of polkit control policies, use man polkit . Modify the libvirt control policies. To do so: Create a new .rules file in the /etc/polkit-1/rules.d/ directory. Add your custom policies to this file, and save it. For further information and examples of libvirt control policies, see the libvirt upstream documentation . Configure your VMs to use access policies determined by polkit . To do so, find all configuration files for virtualization drivers in the /etc/libvirt/ directory, and uncomment the access_drivers = [ "polkit" ] line in them. For each file that you modified in the step, restart the corresponding service. For example, if you have modified /etc/libvirt/virtqemud.conf , restart the virtqemud service. Verification As a user whose VM actions you intended to limit, perform one of the restricted actions. For example, if unprivileged users are restricted from viewing VMs created in the system session: If this command does not list any VMs even though one or more VMs exist on your system, polkit successfully restricts the action for unprivileged users. Troubleshooting Currently, configuring libvirt to use polkit makes it impossible to connect to VMs using the RHEL 9 web console , due to an incompatibility with the libvirt-dbus service. If you require fine-grained access control of VMs in the web console, create a custom D-Bus policy. For more information, see the Red Hat Knowledgebase solution How to configure fine-grained control of Virtual Machines in Cockpit . Additional resources The man polkit command The libvirt upstream information about polkit access control policies include::module/virtualization/proc_ 19.6. SELinux booleans for virtualization RHEL 9 provides the sVirt feature, which is a set of specialized SELinux booleans that are automatically enabled on a host with SELinux in Enforcing mode. For fine-grained configuration of virtual machines security on a RHEL 9 system, you can configure SELinux booleans on the host to ensure the hypervisor acts in a specific way. To list all virtualization-related booleans and their statuses, use the getsebool -a | grep virt command: To enable a specific boolean, use the setsebool -P boolean_name on command as root. To disable a boolean, use setsebool -P boolean_name off . The following table lists virtualization-related booleans available in RHEL 9 and what they do when enabled: Table 19.1. SELinux virtualization booleans SELinux Boolean Description staff_use_svirt Enables non-root users to create and transition VMs to sVirt. unprivuser_use_svirt Enables unprivileged users to create and transition VMs to sVirt. virt_sandbox_use_audit Enables sandbox containers to send audit messages. virt_sandbox_use_netlink Enables sandbox containers to use netlink system calls. virt_sandbox_use_sys_admin Enables sandbox containers to use sys_admin system calls, such as mount. virt_transition_userdomain Enables virtual processes to run as user domains. virt_use_comm Enables virt to use serial/parallel communication ports. virt_use_execmem Enables confined virtual guests to use executable memory and executable stack. virt_use_fusefs Enables virt to read FUSE mounted files. virt_use_nfs Enables virt to manage NFS mounted files. virt_use_rawip Enables virt to interact with rawip sockets. virt_use_samba Enables virt to manage CIFS mounted files. virt_use_sanlock Enables confined virtual guests to interact with the sanlock. virt_use_usb Enables virt to use USB devices. virt_use_xserver Enables virtual machine to interact with the X Window System. 19.7. Setting up IBM Secure Execution on IBM Z When using IBM Z hardware to run a RHEL 9 host, you can improve the security of your virtual machines (VMs) by configuring the IBM Secure Execution feature for the VMs. IBM Secure Execution, also known as Protected Virtualization, prevents the host system from accessing a VM's state and memory contents. As a result, even if the host is compromised, it cannot be used as a vector for attacking the guest operating system. In addition, Secure Execution can be used to prevent untrusted hosts from obtaining sensitive information from the VM. You can convert an existing VM on an IBM Z host into a secured VM by enabling IBM Secure Execution. Important For securing production environments, consult the IBM documentation on fully securing workloads with Secure Execution , which explains how to further secure your workloads. Prerequisites The system hardware is one of the following: IBM z15 or later IBM LinuxONE III or later The Secure Execution feature is enabled for your system. To verify, use: If this command displays any output, your CPU is compatible with Secure Execution. The kernel includes support for Secure Execution. To confirm, use: If the command generates any output, your kernel supports Secure Execution. The host CPU model contains the unpack facility. To confirm, use: If the command generates the above output, your CPU host model is compatible with Secure Execution. The CPU mode of the VM is set to host-model . If the command generates any output, the VM's CPU mode is set correctly. The genprotimg package must be installed on the host. The guestfs-tools package is installed on the host in case you want to modify the VM image directly from the host. You have obtained and verified the IBM Z host key document. For details, see Verifying the host key document in IBM documentation. Procedure Do the following steps on your host : Add the prot_virt=1 kernel parameter to the boot configuration of the host. Update the boot menu: # zipl Use virsh edit to modify the XML configuration of the VM you want to secure. Add <launchSecurity type="s390-pv"/> to the under the </devices> line. For example: [...] </memballoon> </devices> <launchSecurity type="s390-pv"/> </domain> If the <devices> section of the configuration includes a virtio-rng device ( <rng model="virtio"> ), remove all lines of the <rng> </rng> block. Optional: If the VM that you want to secure is using 32 GiB of RAM or more, add the <async-teardown enabled='yes'/> line to the <features></features> section in its XML configuration. This improves the performance of rebooting or stopping such Secure Execution guests. Proceed with the steps in one of the following sections. You can either log in to the guest and configure it manually for Secure Execution or configure the guest image directly from the host by using a script and guestfs-tools . Manually configuring the VM for Secure Execution Do the following steps in the guest operating system of the VM you want to secure. Create a parameter file. For example: In the /boot/loader/entries directory, identify the boot loader entry with the latest version: Retrieve the kernel options line of the boot loader entry: Add the content of the options line and swiotlb=262144 to the created parameters file. Generate a new IBM Secure Execution image. For example, the following creates a /boot/secure-image secured image based on the /boot/vmlinuz-4.18.0-240.el8.s390x image, using the secure-parameters file, the /boot/initramfs-4.18.0-240.el8.s390x.img initial RAM disk file, and the HKD-8651-000201C048.crt host key document. By using the genprotimg utility creates the secure image, which contains the kernel parameters, initial RAM disk, and boot image. Update the VM's boot menu to boot from the secure image. In addition, remove the lines starting with initrd and options , as they are not needed. For example, in a RHEL 8.3 VM, the boot menu can be edited in the /boot/loader/entries/ directory: Create the bootable disk image: Securely remove the original unprotected files. For example: The original boot image, the initial RAM image, and the kernel parameter file are unprotected, and if they are not removed, VMs with Secure Execution enabled can still be vulnerable to hacking attempts or sensitive data mining. Configuring the VM for Secure Execution directly from the host You can use guestfs-tools to modify an existing image without manually booting it. However, use the following examples only in testing and development environments. For securing production environments, see the IBM documentation on fully securing workloads with Secure Execution . Do the following steps on the host . Create a script that contains the host key document and that configures the existing VM to use Secure Execution. For example: Ensure the VM is shut-down. Add the script to the existing VM image by using guestfs-tools and mark it to run on first boot . Boot the VM from the image with the added script. The script runs on first boot, and then shuts down the VM again. As a result, the VM is now configured to run with Secure Execution on the host that has the corresponding host key. Verification On the host, use the virsh dumpxml utility to confirm the XML configuration of the secured VM. The configuration must include the <launchSecurity type="s390-pv"/> element, and no <rng model="virtio"> lines. Additional resources IBM documentation for Secure Execution on Linux IBM documentation on fully securing workloads with Secure Execution IBM documentation on genprotimg Configuring kernel command-line parameters 19.8. Attaching cryptographic coprocessors to virtual machines on IBM Z To use hardware encryption in your virtual machine (VM) on an IBM Z host, create mediated devices from a cryptographic coprocessor device and assign them to the intended VMs. For detailed instructions, see below. Prerequisites Your host is running on IBM Z hardware. The cryptographic coprocessor is compatible with device assignment. To confirm this, ensure that the type of your coprocessor is listed as CEX4 or later. The vfio_ap kernel module is loaded. To verify, use: To load the module, use: The s390utils version supports ap handling: Procedure Obtain the decimal values for the devices that you want to assign to the VM. For example, for the devices 05.0004 and 05.00ab : On the host, reassign the devices to the vfio-ap drivers: Note To assign the devices persistently, use the -p flag. Verify that the cryptographic devices have been reassigned correctly. If the DRIVER values of the domain queues changed to vfio_ap , the reassignment succeeded. Create an XML snippet that defines a new mediated device. The following example shows defining a persistent mediated device and assigning queues to it. Specifically, the vfio_ap.xml XML snippet in this example assigns a domain adapter 0x05 , domain queues 0x0004 and 0x00ab , and a control domain 0x00ab to the mediated device. Create a new mediated device from the vfio_ap.xml XML snippet. Start the mediated device that you created in the step, in this case mdev_8f9c4a73_1411_48d2_895d_34db9ac18f85_matrix . Check that the configuration has been applied correctly If the output contains the numerical values of queues that you have previously assigned to vfio-ap , the process was successful. Attach the mediated device to the VM. Display the UUID of the mediated device that you created and save it for the step. Create and open an XML file for the cryptographic card mediated device. For example: Add the following lines to the file and save it. Replace the uuid value with the UUID you obtained in step a . <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'> <source> <address uuid='8f9c4a73-1411-48d2-895d-34db9ac18f85'/> </source> </hostdev> Use the XML file to attach the mediated device to the VM. For example, to permanently attach a device defined in the crypto-dev.xml file to the running testguest1 VM: The --live option attaches the device to a running VM only, without persistence between boots. The --config option makes the configuration changes persistent. You can use the --config option alone to attach the device to a shut-down VM. Note that each UUID can only be assigned to one VM at a time. Verification Ensure that the guest operating system detects the assigned cryptographic devices. The output of this command in the guest operating system will be identical to that on a host logical partition with the same cryptographic coprocessor devices available. In the guest operating system, confirm that a control domain has been successfully assigned to the cryptographic devices. If lszcrypt -d C displays U and B intersections in the cryptographic device matrix, the control domain assignment was successful. 19.9. Enabling standard hardware security on Windows virtual machines To secure Windows virtual machines (VMs), you can enable basic level security by using the standard hardware capabilities of the Windows device. Prerequisites Make sure you have installed the latest WHQL certified VirtIO drivers. Make sure the VM's firmware supports UEFI boot. Install the edk2-OVMF package on your host machine. Install the vTPM packages on your host machine. Make sure the VM is using the Q35 machine architecture. Make sure you have the Windows installation media. Procedure Enable TPM 2.0 by adding the following parameters to the <devices> section in the VM's XML configuration. <devices> [...] <tpm model='tpm-crb'> <backend type='emulator' version='2.0'/> </tpm> [...] </devices> Install Windows in UEFI mode. For more information about how to do so, see Creating a SecureBoot virtual machine . Install the VirtIO drivers on the Windows VM. For more information about how to do so, see Installing virtio drivers on a Windows guest . In UEFI, enable Secure Boot. For more information about how to do so, see Secure Boot . Verification Ensure that the Device Security page on your Windows machine displays the following message: Settings > Update & Security > Windows Security > Device Security 19.10. Enabling enhanced hardware security on Windows virtual machines To further secure Windows virtual machines (VMs), you can enable virtualization-based protection of code integrity, also known as Hypervisor-Protected Code Integrity (HVCI). Prerequisites Ensure that standard hardware security is enabled. For more information, see Enabling standard hardware security on Windows virtual machines . Ensure you have enabled Hyper-V enlightenments. For more information, see Enabling Hyper-V enlightenments . Procedure Open the XML configuration of the Windows VM. The following example opens the configuration of the Example-L1 VM: Under the <cpu> section, specify the CPU mode and add the policy flag. Important For Intel CPUs, enable the vmx policy flag. For AMD CPUs, enable the svm policy flag. If you do not wish to specify a custom CPU, you can set the <cpu mode> as host-passthrough . <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>Skylake-Client-IBRS</model> <topology sockets='1' dies='1' cores='4' threads='1'/> <feature policy='require' name='vmx'/> </cpu> Save the XML configuration and reboot the VM. On the VMs operating system, navigate to the Core isolation details page: Settings > Update & Security > Windows Security > Device Security > Core isolation details Toggle the switch to enable Memory Integrity . Reboot the VM. Note For other methods of enabling HVCI, see the relevant Microsoft documentation. Verification Ensure that the Device Security page on your Windows VM displays the following message: Settings > Update & Security > Windows Security > Device Security Alternatively, check System Information about the Windows VM: Run msinfo32.exe in a command prompt. Check if Credential Guard, Hypervisor enforced Code Integrity is listed under Virtualization-based security Services Running .

Commands:
getenforce Enforcing
dnf install edk2-ovmf
virt-install --name rhel8sb --memory 4096 --vcpus 4 --os-variant rhel9.0 --boot uefi,nvram_template=/usr/share/OVMF/OVMF_VARS.secboot.fd --disk boot_order=2,size=10 --disk boot_order=1,device=cdrom,bus=scsi,path=/images/RHEL-9.0-installation.iso
mokutil --sb-state SecureBoot enabled
ls /usr/share/polkit-1/actions | grep libvirt ls /usr/share/polkit-1/rules.d | grep libvirt
find /etc/libvirt/ -name virt*d.conf -exec sed -i 's/#access_drivers = \[ "polkit" \]/access_drivers = \[ "polkit" \]/g' {} +
systemctl try-restart virtqemud
virsh -c qemu:///system list --all Id Name State -------------------------------
getsebool -a | grep virt [...] virt_sandbox_use_netlink --> off virt_sandbox_use_sys_admin --> off virt_transition_userdomain --> off virt_use_comm --> off virt_use_execmem --> off virt_use_fusefs --> off [...]
grep facilities /proc/cpuinfo | grep 158
ls /sys/firmware | grep uv
virsh domcapabilities | grep unpack <feature policy='require' name='unpack'/>
virsh dumpxml <vm_name> | grep "<cpu mode='host-model'/>"
dnf install genprotimg
dnf install guestfs-tools
grubby --update-kernel=ALL --args="prot_virt=1"
[...] </memballoon> </devices> <launchSecurity type="s390-pv"/> </domain>
touch ~/secure-parameters
ls /boot/loader/entries -l [...] -rw-r--r--. 1 root root 281 Oct 9 15:51 3ab27a195c2849429927b00679db15c1-4.18.0-240.el8.s390x.conf
cat /boot/loader/entries/3ab27a195c2849429927b00679db15c1-4.18.0-240.el8.s390x.conf | grep options options root=/dev/mapper/rhel-root rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap
echo "root=/dev/mapper/rhel-root rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap swiotlb=262144" > ~/secure-parameters
genprotimg -i /boot/vmlinuz-4.18.0-240.el8.s390x -r /boot/initramfs-4.18.0-240.el8.s390x.img -p ~/secure-parameters -k HKD-8651-00020089A8.crt -o /boot/secure-image
cat /boot/loader/entries/3ab27a195c2849429927b00679db15c1-4.18.0-240.el8.s390x.conf title Red Hat Enterprise Linux 8.3 version 4.18.0-240.el8.s390x linux /boot/secure-image [...]
zipl -V
shred /boot/vmlinuz-4.18.0-240.el8.s390x shred /boot/initramfs-4.18.0-240.el8.s390x.img shred secure-parameters
#!/usr/bin/bash echo "USD(cat /proc/cmdline) swiotlb=262144" > parmfile cat > ./HKD.crt << EOF -----BEGIN CERTIFICATE----- 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 1234569901234569901234569901234569901234569901234569901234569900 xLPRGYwhmXzKDg== -----END CERTIFICATE----- EOF version=USD(uname -r) kernel=/boot/vmlinuz-USDversion initrd=/boot/initramfs-USDversion.img genprotimg -k ./HKD.crt -p ./parmfile -i USDkernel -r USDinitrd -o /boot/secure-linux --no-verify cat >> /etc/zipl.conf<< EOF [secure] target=/boot image=/boot/secure-linux EOF zipl -V shutdown -h now
virt-customize -a <vm_image_path> --selinux-relabel --firstboot <script_path>
virsh dumpxml vm-name [...] <cpu mode='host-model'/> <devices> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='native'> <source file='/var/lib/libvirt/images/secure-guest.qcow2'/> <target dev='vda' bus='virtio'/> </disk> <interface type='network'> <source network='default'/> <model type='virtio'/> </interface> <console type='pty'/> <memballoon model='none'/> </devices> <launchSecurity type="s390-pv"/> </domain>
lszcrypt -V CARD.DOMAIN TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER -------------------------------------------------------------------------------------------- 05 CEX5C CCA-Coproc online 1 0 11 08 S--D--N-- cex4card 05.0004 CEX5C CCA-Coproc online 1 0 11 08 S--D--N-- cex4queue 05.00ab CEX5C CCA-Coproc online 1 0 11 08 S--D--N-- cex4queue
lsmod | grep vfio_ap vfio_ap 24576 0 [...]
modprobe vfio_ap
lszdev --list-types ap Cryptographic Adjunct Processor (AP) device
echo "obase=10; ibase=16; 04" | bc 4 echo "obase=10; ibase=16; AB" | bc 171
chzdev -t ap apmask=-5 aqmask=-4,-171
lszcrypt -V CARD.DOMAIN TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER -------------------------------------------------------------------------------------------- 05 CEX5C CCA-Coproc - 1 0 11 08 S--D--N-- cex4card 05.0004 CEX5C CCA-Coproc - 1 0 11 08 S--D--N-- vfio_ap 05.00ab CEX5C CCA-Coproc - 1 0 11 08 S--D--N-- vfio_ap
vim vfio_ap.xml <device> <parent>ap_matrix</parent> <capability type="mdev"> <type id="vfio_ap-passthrough"/> <attr name='assign_adapter' value='0x05'/> <attr name='assign_domain' value='0x0004'/> <attr name='assign_domain' value='0x00ab'/> <attr name='assign_control_domain' value='0x00ab'/> </capability> </device>
virsh nodedev-define vfio_ap.xml Node device 'mdev_8f9c4a73_1411_48d2_895d_34db9ac18f85_matrix' defined from 'vfio_ap.xml'
virsh nodedev-start mdev_8f9c4a73_1411_48d2_895d_34db9ac18f85_matrix Device mdev_8f9c4a73_1411_48d2_895d_34db9ac18f85_matrix started
cat /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough/devices/ 669d9b23-fe1b-4ecb-be08-a2fabca99b71 /matrix 05.0004 05.00ab
virsh nodedev-dumpxml mdev_8f9c4a73_1411_48d2_895d_34db9ac18f85_matrix <device> <name>mdev_8f9c4a73_1411_48d2_895d_34db9ac18f85_matrix</name> <parent>ap_matrix</parent> <capability type='mdev'> <type id='vfio_ap-passthrough'/> <uuid>8f9c4a73-1411-48d2-895d-34db9ac18f85</uuid> <iommuGroup number='0'/> <attr name='assign_adapter' value='0x05'/> <attr name='assign_domain' value='0x0004'/> <attr name='assign_domain' value='0x00ab'/> <attr name='assign_control_domain' value='0x00ab'/> </capability> </device>
vim crypto-dev.xml
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'> <source> <address uuid='8f9c4a73-1411-48d2-895d-34db9ac18f85'/> </source> </hostdev>
virsh attach-device testguest1 crypto-dev.xml --live --config
lszcrypt -V CARD.DOMAIN TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER -------------------------------------------------------------------------------------------- 05 CEX5C CCA-Coproc online 1 0 11 08 S--D--N-- cex4card 05.0004 CEX5C CCA-Coproc online 1 0 11 08 S--D--N-- cex4queue 05.00ab CEX5C CCA-Coproc online 1 0 11 08 S--D--N-- cex4queue
lszcrypt -d C DOMAIN 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ------------------------------------------------------ 00 . . . . U . . . . . . . . . . . 10 . . . . . . . . . . . . . . . . 20 . . . . . . . . . . . . . . . . 30 . . . . . . . . . . . . . . . . 40 . . . . . . . . . . . . . . . . 50 . . . . . . . . . . . . . . . . 60 . . . . . . . . . . . . . . . . 70 . . . . . . . . . . . . . . . . 80 . . . . . . . . . . . . . . . . 90 . . . . . . . . . . . . . . . . a0 . . . . . . . . . . . B . . . . b0 . . . . . . . . . . . . . . . . c0 . . . . . . . . . . . . . . . . d0 . . . . . . . . . . . . . . . . e0 . . . . . . . . . . . . . . . . f0 . . . . . . . . . . . . . . . . ------------------------------------------------------ C: Control domain U: Usage domain B: Both (Control + Usage domain)
{PackageManagerCommand} install edk2-ovmf
{PackageManagerCommand} install swtpm libtpms
<devices> [...] <tpm model='tpm-crb'> <backend type='emulator' version='2.0'/> </tpm> [...] </devices>
Your device meets the requirements for standard hardware security.
virsh edit Example-L1
<cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>Skylake-Client-IBRS</model> <topology sockets='1' dies='1' cores='4' threads='1'/> <feature policy='require' name='vmx'/> </cpu>
Your device meets the requirements for enhanced hardware security.