Patent Publication Number: US-2023145134-A1

Title: Secure modular devices

Description:
CROSS REFERENCES TO RELATED APPLICATIONS 
     This application is a continuation U.S. Pat. Application No. 16/863,250, filed on Apr. 30, 2020, the entire content of which is hereby incorporated by reference. 
    
    
     BACKGROUND 
     A virtual machine is software that is executed on hardware to create a virtualization of a physical computer system. Virtual machines may function as self-contained platforms that run their own operating systems and software applications. A host machine, such as a server computer may concurrently run one or more virtual machines using a hypervisor. The hypervisor allocates a certain amount of the host’s resources, such as the host’s underlying physical processors and memory devices, to each of the virtual machines, allowing the virtual machines to transparently access the host’s resources. Each virtual machine may use the allocated resources to execute applications, including operating systems referred to as guest operating systems. Each guest operating system may be accessed by one or more local or remote clients to perform computing tasks. 
     SUMMARY 
     The present disclosure provides new and innovative systems and methods for securely communicating with virtual devices. In an example, a method includes initializing a secure interface configured to provide access to a virtual machine (VM) from a device, where the VM is associated with a level of security. A buffer is allocated and associated with the secure interface. The amount of access to guest memory of the VM is indicated by the level of security. Next, the buffer is provided to the device and inputs / outputs (I/Os) can be sent between the device and the VM using the secure interface. 
     In an example, a system includes a memory and a processor. The memory is in communication with the processor and configured to initialize a secure interface configured to provide access to a virtual machine (VM) from a device, where the VM is associated with a level of security. A buffer is allocated and associated with the secure interface, where the level of security of the VM indicates whether the device has access to guest memory of the VM via the buffer. The buffer is then provided to the device. Inputs / outputs (I/Os) are sent between the device and the VM using the secure interface. 
     In an example, a non-transitory machine readable medium storing code, which when executed by a processor, is configured to initialize a secure interface configured to provide access to a virtual machine (VM) from a device, where the VM is associated with a level of security. A buffer is allocated and associated with the secure interface. The level of security of the VM indicates whether the device has access to guest memory of the VM via the buffer. Next, the buffer is provided to the device and inputs / outputs (I/Os) are sent between the device and the VM using the secure interface. 
     Additional features and advantages of the disclosed method and apparatus are described in, and will be apparent from, the following Detailed Description and the Figures. The features and advantages described herein are not all-inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the figures and description. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIG.  1    illustrates a high level component diagram of an example computing system in accordance with one or more aspects of the present disclosure. 
         FIG.  2    illustrates a component diagram of an example computing system communicating with a virtual device in accordance with one or more aspects of the present disclosure. 
         FIG.  3    illustrates a flowchart of an example method of communicating with a device according to an example embodiment of the present disclosure. 
         FIG.  4    illustrates a flow diagram of example methods connecting a device to a virtual machine (VM), in accordance with an embodiment of the present disclosure. 
         FIG.  5    illustrates a block diagram of an example system communicating with a device according to an example embodiment of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Techniques are disclosed for providing a variably secure connection between a virtual machine and a device. With the use of virtual machines (VMs) becoming more prominent in industry, it is apparent that there is a need for better security for device communication with a VM. Traditionally, best practice is that devices should be implemented as modular processes with access to only part of a VM’s memory. However, typically, updating page tables for all virtual devices for every change is so challenging that many hypervisor actually disable security and map all of guest memory into each device. Generally, a guest OS of a VM needs the ability to reallocate its memory in a flexible way (e.g., moving a device from kernel to user-space control) and, as such, the industry would benefit from innovations that could improve communication with virtual machines. 
     As described in various examples disclosed herein, to facilitate security when using virtual machines, the systems and methods disclosed herein advantageously providing a device varying levels of access to guest memory of a VM based on an amount of security desired by the VM. In various examples, a VM may have a security level or may rate various devices with different levels of security depending on their source. The VM may vary the amount of access given to a device by deciding whether to use a secure buffer. For example, if a VM determines that a device is trusted or requires a low level of security, the VM will provide access to at least a portion of the guest OS’s memory. In some instances, the VM will provide access to all of the guest OS’s memory. If a VM determines that a device is not trusted or requires a higher level of security, the VM initializes a software input output translation lookaside buffer (SWIOTLB) and attaches the SWIOTLB to the device memory buffer (e.g., PCI device memory). Next the VM notifies the hypervisor that the VM wants extra security and the hypervisor shares the SWIOTLB with the device process instead of sharing VM memory. In some instances, a hypervisor may set and/or modify permissions of the buffer. 
     In various examples, a device deemed by a VM to require a high level of security may include, but not limited to, a userspace driver and/or a public storage. A trusted device, or a device requiring a low level of security, may include, but not limited to, trusted manufacturer drivers, trusted data sources, and/or devices known to the VM. In various instances, a low level of security may mean that full access to VM memory is provided. In these instances, a high level of security may mean that one or more security measures are used to protect the VM and VM memory. In some instances, one or more security measures may include using a SWIOTLB instead of providing VM memory. 
       FIG.  1    depicts a high-level component diagram of an example computing system  100  in accordance with one or more aspects of the present disclosure. The computing system  100  may include a server  180 , a device  110 , one or more virtual machines (VM  170 A-B,  170  generally), and nodes (e.g., nodes  110 A-C,  110  generally). The server  180  may include a hypervisor  105 , which may create and/or run the VMs  170 . 
     Virtual machines  170 A-B may include a virtual machine memory (VM Memory), a virtual CPU (VCPU), virtual memory devices (VMD), and virtual input/output devices (VI/O). For example, virtual machine  170 A may include virtual machine memory  195 A, a virtual CPU  190 A, a virtual memory devices  193 A, and a virtual input/output device  194 A. Similarly, virtual machine  170 B may include virtual machine memory  195 B, a virtual CPU  190 B, a virtual memory devices  193 B, and virtual input/output device  194 B. In an example, Applications  198 A-D may be different applications or services. In another example, applications  198 A-D may be different instances of the same application or service. 
     In an example, a virtual machine  170 A may execute a guest operating system and run applications  198 A-B which may utilize the underlying VCPU  190 A, VMD  193 A, and VI/O device  194 A. One or more applications  198 A-B may be running on a virtual machine  170 A under the respective guest operating system. A virtual machine (e.g., VM  170 A-B, as illustrated in  FIG.  1   ) may run on any type of dependent, independent, compatible, and/or incompatible applications on the underlying hardware and operating system (“OS”). In an example, applications (e.g., App  198 A-B) run on a virtual machine  170 A may be dependent on the underlying hardware and/or OS. In another example embodiment, applications  198 A-B run on a virtual machine  170 A may be independent of the underlying hardware and/or OS. For example, applications  198 A-B run on a first virtual machine  170 A may be dependent on the underlying hardware and/or OS while applications (e.g., application  198 C-D) run on a second virtual machine (e.g., VM  170 B) are independent of the underlying hardware and/or OS. Additionally, applications  198 A-B run on a virtual machine  170 A may be compatible with the underlying hardware and/or OS. In an example embodiment, applications  198 A-B run on a virtual machine  170 A may be incompatible with the underlying hardware and/or OS. For example, applications  198 A-B run on one virtual machine  170 A may be compatible with the underlying hardware and/or OS while applications  198 C-D run on another virtual machine  170 B are incompatible with the underlying hardware and/or OS. 
     In an example, virtual machines  170 A-B may instead be containers that execute applications or services, such as microservices. In an example, the containers may each run a process or service and the containers may be any execution environment. For example, the containers may be a virtual server. It should be appreciated that containers may be stand alone execution environments, similar to that of a virtual machine. The applications  198 A-D or services (e.g., microservices) may run in a software container or a virtual machine (e.g., virtual machines  170 A-B). 
     The computer system  100  may include one or more nodes  110 A-C. Each node  110 A-C may in turn include one or more physical processors (e.g., CPU  120 A-E) communicatively coupled to memory devices (e.g., MD  130 A-D) and input/output devices (e.g., I/O  140 A-C). Each node  110 A-C may be a computer, such as a physical machine and may include a device, such as hardware device. In an example, a hardware device may include a network device (e.g., a network adapter or any other component that connects a computer to a computer network), a peripheral component interconnect (PCI) device, storage devices, disk drives, sound or video adaptors, photo/video cameras, printer devices, keyboards, displays, etc. Virtual machines  170 A-B may be provisioned on the same host or node (e.g., node  110 A) or different nodes. For example, VM  170 A and VM  170 B may both be provisioned on node  110 A. Alternatively, VM  170 A may be provided on node  110 A while VM  170 B is provisioned on node  110 B. 
     As used herein, physical processor or processor  120 A-E refers to a device capable of executing instructions encoding arithmetic, logical, and/or I/O operations. In one illustrative example, a processor may follow Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In a further aspect, a processor may be a single core processor which is typically capable of executing one instruction at a time (or process a single pipeline of instructions), or a multi-core processor which may simultaneously execute multiple instructions. In another aspect, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A processor may also be referred to as a central processing unit (CPU). 
     As discussed herein, a memory device  130 A-D refers to a volatile or nonvolatile memory device, such as RAM, ROM, EEPROM, or any other device capable of storing data. As discussed herein, I/O device  140 A-C refers to a device capable of providing an interface between one or more processor pins and an external device capable of inputting and/or outputting binary data. 
     Processors (e.g., CPUs  120 A-E) may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network. Local connections within each node, including the connections between a processor  120 A-E and a memory device  130 A-D may be provided by one or more local buses of suitable architecture, for example, peripheral component interconnect (PCI). 
       FIG.  2    illustrates a component diagram of an example computing system communicating with a virtual device in accordance with one or more aspects of the present disclosure. As shown, the computer system  200  includes a host machine  205  and devices ( 270 A-B,  270  generally). The host machine  205  includes virtual machine  210 , host OS  230 , and host hardware  250 . The virtual machine  210  includes Guest OS  215 , which includes applications  220  and guest memory  225 . Host OS  230  includes hypervisor  235 , which manages virtual device  240 . Host hardware  250  includes processor  255 , memory device  260 , and I/O device  265 . In various examples, device  270  may be a userspace driver. In some examples, device  270  may be a trusted data source. In various examples, the device  270  may be a virtual device. 
     As shown in  FIG.  2   , the virtual machine  210  is capable of having secure communication with devices ( 270 A-B,  270  generally). The guest OS  215  may determine whether to request extra security when communicating with a device  270  based on a level of security. For example, device  270 A is a trusted device and the VM  210  requires a low level of security when communicating with a trusted device. As such, guest OS  215  initializes a secure interface  275  and allocates a buffer for the device  270 A from guest memory  225 . Upon providing the buffer to the device  270 A, the device  270 A, in this instance, has complete access to guest memory  225  through the secure interface  275  during communication between device  270 A and virtual machine  210 . In some instances, the guest OS  215  is capable of providing only a portion of the guest memory  225  through the secure interface  275 . In these instances, a guest OS  215  may limit which portions of guest memory  225  the device  270 A can access. 
     By contrast, guest OS  215  determines that device  270 B requires a higher level of security than device  270 A. As such, guest OS  215  initializes a secure interface  275  and requests a buffer from hypervisor  235 . Hypervisor  235  creates a virtual device  240  that has device memory  245 ; the device memory  245  is accessible by the guest OS  215  and can appear to be a PCI device. The hypervisor  235  configures the security of the device memory  245  and shares access to the device memory to device  270 B. In various instances, configuring security of a buffer may include setting permissions of the buffer. A communication link to the guest OS  215  is created when the device  270 B receives access to the device memory  245 . 
     In this configuration, device  270 B does not have direct access to guest memory  225  and guest OS  215  has direct control over what is copied into guest memory  225  from the device memory  245 . Any information sent by device  270 B is first copied into device memory  245 . Once guest OS  215  is ready for the information, the information is copied from device memory  245  into guest memory  225 . Additionally, any information sent to device  270 B from guest OS  215  is first copied into device memory  245  from guest memory  225  and subsequently copied into the memory space of device  270 B. 
       FIG.  3    illustrates a flowchart of an example method of communicating with a device, in accordance with an embodiment of the present disclosure. Although the example method  300  is described with reference to the flowchart illustrated in  FIG.  3   , it will be appreciated that many other methods of performing the acts associated with the method  300  may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, blocks may be repeated and some of the blocks described are optional. The method  300  may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both. 
     As shown, a secure interface is initialized (block  305 ). For example, a guest OS  215  on virtual machine  210  initializes a secure interface  275  to communicate with a device  270 . In various instances, the virtual machine  210  is associated with a level of security. In some instances, the virtual machine  210  may adjust a level of security based on the device wanting to communicate with the virtual machine  210 . In this instance, a buffer is allocated and associated with the secure interface, where a level of security indicates an amount of access to guest memory is provided to the device (block  310 ). For example, upon determining there needs to be a low amount of security between the guest OS  215  and the device  270 A, the guest OS allocates a buffer from guest memory  225 . If a higher level of security between the guest OS  215  and the device  270 B is required, the guest OS  215  requests that the hypervisor  235  create a software input output translation lookaside buffer (SWIOTLB) in the form of device memory  245  at the hypervisor  235 . Next, the buffer is provided to the device (block  315 ). For example, when communicating with device  270 A, a buffer from guest memory  225  is provided. When communicating with device  270 B, hypervisor  235  provides device memory  245  to device  270 B. Upon completing the communication link, inputs/outputs (I/Os) can be sent between the device and VM (block  320 ). For example, device  270 B can send an I/O to guest OS  215  by copying data to device memory  245 . Guest OS  215  then retrieves the data from device memory via the secure interface  275 . 
       FIG.  4    illustrates a flow diagram of an example methods of communicating with a device, in accordance with an embodiment of the present disclosure. Although the example method  400  is described with reference to the flow diagram illustrated in  FIG.  4   , it will be appreciated that many other methods of performing the acts associated with the method  400  may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, blocks may be repeated, and some of the blocks described are optional. For example, in the illustrated flow diagram, a virtual machine  210  is in communication with a hypervisor  235  when communicating with a device  270 , where device  270 A requires a low amount of security and device  270 B requires a high amount of security. 
     Connecting to a VM  210  with low security requirements (block  405 ) may mean that a device  270 A is trusted and/or the source of the device  270 A is trusted. As shown, a guest OS  215  of VM  210  initializes a secure interface  275  to connect to device  270 A (block  415 ). The guest OS  215  then allocates a buffer from guest memory  225  (block  420 ) and associates the buffer with the secure interface  275  (block  425 ). The guest OS  215  provides the buffer to the device  270 A (block  430 ). Upon receiving access to the buffer (block  435 ), a communication link between the virtual machine  210  and device  270 A is complete. At this point, the device  270 A can send and receive inputs / outputs (I/Os) (block  440 ) which can be received by the virtual machine  210  (block (445). 
     Connecting a VM  210  with device  270 B is a different process due to a high amount of security required to secure the VM  210  (block  410 ) with respect to device  270 B. The high level of security may mean that the device  270 B is from an uncertain source, not a trusted device, and/or a user-space driver. These types of devices may potentially not be reliable and may potentially cause errors or create security issues when communicating with the VM  210  if allowed full access to guest memory  225 . Also, a high level of security may be an attribute of the VM  210 , such that the processes running within VM  210  need to be protected from insecure or unreliable devices. In this instance, the VM  210  initializes a secure interface  275  (block  450 ) and requests a buffer from hypervisor  235  (block  455 ). The hypervisor  235  creates a virtual device  240  and allocates device memory  245  (block  460 ) to be a buffer for the secured interface  275 . The hypervisor  235  configures security for the device memory  245  (block  465 ) and shares access to the device memory  245  (block  470 ) to the VM  215  (block  480 ) and to the device  270 B (block  475 ). Next, the device  270 B can send inputs / outputs (I/Os) (block  485 ) and VM  210  can receive I/Os (block  490 ). 
       FIG.  5    is a block diagram of system  500  which includes memory  510  and processor  505 . The processor  505  is in communication with the memory  510 . The processor  505  initializes a secure interface  515  configured to provide access to a virtual machine  525  from a device  545 . The VM  525  is associated with a level of security  535 . A buffer  520  is allocated and associated with the secure interface  515 . The level of security  535  indicates whether the device  545  has access to guest memory  530  of the VM  525  through the buffer  520 . The buffer  520  is then provided to the device  545  and Input/Outputs (I/Os)  540  are sent between the device  545  and the VM  525  using the secure interface  515 . 
     It will be appreciated that all of the disclosed methods and procedures described herein can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer readable medium or machine readable medium, including volatile or non-volatile memory, such as RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be provided as software or firmware, and/or may be implemented in whole or in part in hardware components such as ASICs, FPGAs, DSPs or any other similar devices. The instructions may be configured to be executed by one or more processors, which when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures. 
     It should be understood that various changes and modifications to the example embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.