110 to control what memory can be accessed by an I/O device (e.g., the kernel inspector device 118) on a bus (e.g., the bus 116).

Once the IOMMU is set up by the hypervisor 112 to allow the physical memory locations associated with each virtual memory 17j to be accessed by the kernel inspector device 118, the processing resource 110 can automatically and transparently handle address translations, DMA mapping, and memory encryption and decryption. In further examples, a virtual IOMMU may be provided in each VM to allow the VM to control what virtual memory may be accessed by an I/O device such as the kernel inspector device 118.

In addition to providing or enabling the intrusion monitoring driver 16j in each VM 10j to allow monitoring of the kernel information 15j, DMA access also has to be enabled (such as by the hypervisor 112) to allow the kernel inspector device 118 to access the kernel information 15j. In other words, if the intrusion monitoring driver 16j is not present or disabled, or if DMA access is not enabled, the kernel inspector device 118 would not be able to inspect the VM 10j.

FIG. 2 is a flow diagram of a process of the kernel inspection engine 130 according to some examples. The kernel inspection engine 130 obtains (at 202), using respective virtual I/O devices 141 to 14N, addresses of virtual memories (of the VMs 101 to 10N) that are to be monitored for integrity inspection of guest OS kernel information. For example, the kernel inspection engine 130 can issue requests (through the virtual I/O devices 141 to 14N) to respective intrusion monitoring drivers 161 to 16N for the addresses of the virtual memories 171 to 17N at which guest OS kernel information 151 to 15N are stored. As another example, the respective intrusion monitoring drivers 161 to 16N can push, to the kernel inspection engine 130, the addresses of the virtual memories 171 to 17N at which guest OS kernel information 151 to 15N are stored. The obtaining of the addresses of virtual memories at which guest OS kernel information 151 to 15N are stored can be performed by the kernel inspection engine 130 right after secure initialization and measured boot of each VM 10j, when it is likely that the VM 10j is still in a secure state (i.e., has not yet loaded any malware).

In response to receiving the addresses of the guest OS kernel information, the kernel inspection engine 130 retrieves (at 204), using DMA, the guest OS kernel information 15j from the virtual memory 17j of each respective VM 10j. More specifically, the kernel inspection engine 130 uses a corresponding virtual I/O device 14j to retrieve, using DMA, the guest OS kernel information 15j from the virtual memory 17j.

The kernel inspection engine 130 then applies (at 206) integrity inspection of each retrieved guest OS kernel information 15j. The integrity inspection is to confirm that the guest OS kernel information 15j has not deviated from a known good state. In some examples, the guest OS kernel information 15j can compute a cryptographic hash based on the content of a portion of the guest OS kernel information 15j. The portion of the guest OS kernel information 15j can include the entire guest OS kernel information 15j or a partial part of the guest OS kernel information 15j. The guest OS kernel information 15j can compare the cryptographic hash value derived from the portion of the guest OS kernel information 15j to a reference cryptographic hash value. If the derived cryptographic hash value does not match the reference cryptographic hash value, then that indicates that the guest OS kernel information 15j may have been compromised.

In response to detecting that the guest OS kernel information 15j has been compromised, the kernel inspection engine 130 can initiate (at 208) a remediation action. The remediation action can include any or some combination of the following: shutting down or otherwise disabling the VM 10j associated with the compromised guest OS kernel information 15j, replacing the guest OS kernel 13j with a known good version of the guest OS kernel 13j, performing a malware removal process to attempt to remove any malware from the guest OS kernel 13j, sending an alert to a target entity (e.g., a human administrator, a management program, a management machine, etc.), or any other remediation action.

In some examples, the guest OS kernel information 15j stored in the virtual memory 17j may be encrypted, such as in cases where the VM 10j is an encrypted VM. Examples of encrypted VMs include those that execute WINDOWS OS or other OSes. In other examples, the VMs are not encrypted, such as VMs that employ other types of the OSes, including Linux OS, UNIX OS, MAC OS, and so forth.

By utilizing the support by the processing resource 110 for I/O (e.g., using SRIOV or SIOV) to access the virtual memory 17j by the kernel inspector device 118, the encrypted guest OS kernel information 15j may be automatically decrypted, such as by a memory controller 120 of the electronic device 100, before the guest OS kernel information 15j is transferred to the kernel inspector device 118. This allows more efficient usage of processing resources since the kernel inspector device 118 would not have to be configured with the ability to decrypt encrypted guest OS kernel information. Note that in some cases, moving memory content (e.g., including the guest OS kernel information 15j) from one physical memory location (associated with the virtual memory 17j) to another physical memory location (associated with the kernel inspector device 118) may change the encrypted content, since the address of the memory content may be used as an input to an encryption algorithm to mitigate page substitution attacks. By using the memory controller 120 to decrypt the encrypted guest OS kernel information 15j, the encrypted guest OS kernel information 15j can be decrypted prior to moving the guest OS kernel information 15j to the kernel inspector device 118.

FIG. 3 is a block diagram of an electronic device 300 according to alternative examples of the present disclosure. The electronic device 300 includes the processing resource 110, the bus 116, and the physical resources 114.

The electronic device 300 uses an inspector VM 302 to perform integrity inspection of respective VMs 101 to 10N. The elements of the VMs 101 to 10N are similar to those depicted in FIG. 1 and are assigned the same reference numerals.

In FIG. 3, the inspector VM 302 rather than the kernel inspector device 118 is used to perform integrity inspection of guest OS kernels. In some examples, the inspector VM 302 is executed by the processing resource 110 that also executes the other VMs 101 to 10N whose guest OS kernels 131 to 13N are subject to integrity inspection by the inspector VM 302. In other examples, the inspector VM 302 is executed by a processing resource separate from the processing resource 110.

The kernel inspector device 118 of FIG. 1 has sufficient processing capacity to perform integrity inspection of guest OS kernel information, which can involve computations of cryptographic hash values and using those cryptographic hash values to determine whether the guest OS kernel information has been compromised. Computing cryptographic hash values can be processing intensive so that a relatively large capacity processing device, such as a data processing unit (DPU) or other type of processing device, would have to be used. A relatively large capacity processing device can be expensive and can add to the overall cost of an electronic device.

By performing VM guest OS kernel integrity inspection using the inspector VM 302, a relatively large capacity processing device would not have to be employed. The inspector VM 302 can use a relatively small capacity processing device to obtain guest OS kernel information 151 to 15N from the respective VMs 101 to 10N. The relatively small capacity processing device can be in the form of a memory capture device 304 in place of the kernel inspector device 118 of FIG. 1. The memory capture device 304 is a bus device connected to the bus 116 (e.g., a PCIe bus). The memory capture device 304 can be implemented with a microcontroller or other hardware processing device that has less processing capacity than the kernel inspector device 118. As a result, the hardware cost associated with performing integrity inspection of the VMs can be reduced, since the memory capture device 304 can be a relatively low cost hardware device.

In some examples, the memory capture device 304 may be implemented as part of the BMC of the electronic device 300. In other examples, the memory capture device 304 is separate from the BMC. The memory capture device 304 is also separate from the processing resource 110.

The memory capture device 304 can also implement I/O virtualization such as SRIOV or SIOV, for example. The I/O virtualization performed by the memory capture device 304 provides virtual I/O devices 341 to 34N that can be used to establish communication channels with corresponding intrusion monitoring drivers 161 to 16N of the VMs 101 to 10N.

The I/O virtualization performed by the memory capture device 304 also provides a virtual I/O device 306 that can be used to establish a communication channel with an intrusion monitoring driver 308 in the inspector VM 302. The intrusion monitoring driver 308 is similar to the intrusion monitoring drivers 161 to 16N in the VMs 101 to 10N.

In an example where the I/O virtualization used is SIOV, the inspector VM 302 constitutes a privileged SIOV endpoint that is to be authenticated and authorized by the memory capture device 304. If the inspector VM 302 is successfully authenticated and authorized by the memory capture device 304 (such as based on use of credentials or keys), then the inspector VM 302 is a privileged VM that is able to gain access of the guest OS kernel information 151 to 15N of other VMs 101 to 10N for integrity inspection. The intrusion monitoring driver 308 in the inspector VM 302 is able to establish a privileged communication channel 314 with the virtual I/O device 306 in the memory capture device 304. An example of the privileged communication channel 314 is a privileged SIOV channel. A “privileged communication channel” can refer to a communication channel (e.g., a virtual communication channel between virtual entities) that has privileges not available to non-privileged communication channels, such as those established between the intrusion monitoring drivers 161 to 16N of the respective VMs 101 to 10N.

One such privilege is the ability to obtain addresses of the virtual memories 171 to 17N containing the guest OS kernel information 151 to 15N. Another privilege is the ability to obtain the guest OS kernel information 151 to 15N from the virtual memories 171 to 17N.

The inspector VM 302 includes a guest OS 310 and a kernel inspection program 312. The kernel inspection program 312 can perform tasks similar to those of the kernel inspection engine 130 of FIG. 1.

FIG. 4 is a flow diagram of a process performed by the inspector VM 302. The kernel inspection program 312 obtains (at 402) over the privileged communication channel 314 addresses of virtual memories (of the VMs 101 to 10N) that are to be monitored for integrity inspection of guest OS kernel information. In FIG. 3, the addresses are provided from the VMs 101 to 10N to the virtual I/O devices 341 to 34N in the memory capture device 304, which in turn provide the addresses to the virtual I/O device 306 for communication over the privileged communication channel 314 to the inspector VM 302.

In some examples, the kernel inspection program 312 also obtains identities of the VMs 101 to 10N. An “identity” of a VM can refer to any unique identifier of the VM.

In some examples, the kernel inspection program 312 can issue requests (through the memory capture device 304) to respective VMs 101 to 10N for the addresses of the virtual memories 171 to 17N at which guest OS kernel information 151 to 15N are stored. Each request can include an identity of the respective VM, and the address of the virtual memory from which the guest OS kernel information is to be retrieved. In other examples, the respective intrusion monitoring drivers 161 to 16N of the VMs 101 to 10N can push, to the inspector VM 302, the identities of the VMs 101 to 10N and the addresses of the virtual memories 171 to 17N at which guest OS kernel information 151 to 15N are stored.

In response to receiving the addresses of the guest OS kernel information, the kernel inspection program 312 retrieves (at 404) the guest OS kernel information 15j from the virtual memory 17j of each respective VM 10j. More specifically, the kernel inspection program 312 can issue requests for the guest OS kernel information 151 to 15N at their respective addresses. The requests are issued over the privileged communication channel 314 to the memory capture device 304. These requests are passed by the virtual I/O device 306 in the memory capture device 304 to the respective virtual I/O devices 341 to 34N, which in turn forwards the requests to the VMs 101 to 10N to perform DMA access the virtual memories 171 to 17N. In response to the requests, the intrusion monitoring drivers 161 to 16N in the VMs 101 to