US20220261264A9 - Systems and Methods Involving Aspects of Hardware Virtualization such as Separation Kernel Hypervisors, Hypervisors, Hypervisor Guest Context, Hypervisor Context, Anti-Fingerprinting and/or Other Features - Google Patents
Systems and Methods Involving Aspects of Hardware Virtualization such as Separation Kernel Hypervisors, Hypervisors, Hypervisor Guest Context, Hypervisor Context, Anti-Fingerprinting and/or Other Features Download PDFInfo
- Publication number
- US20220261264A9 US20220261264A9 US17/088,460 US202017088460A US2022261264A9 US 20220261264 A9 US20220261264 A9 US 20220261264A9 US 202017088460 A US202017088460 A US 202017088460A US 2022261264 A9 US2022261264 A9 US 2022261264A9
- Authority
- US
- United States
- Prior art keywords
- guest operating
- operating system
- virtual
- guest
- hypervisor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000926 separation method Methods 0.000 title claims abstract description 78
- 238000000034 method Methods 0.000 title claims abstract description 42
- 238000012545 processing Methods 0.000 claims abstract description 22
- 230000007246 mechanism Effects 0.000 claims description 119
- 238000012544 monitoring process Methods 0.000 claims description 23
- 238000001514 detection method Methods 0.000 claims description 19
- 238000002955 isolation Methods 0.000 claims description 15
- 230000006870 function Effects 0.000 claims description 6
- 230000009471 action Effects 0.000 claims description 5
- 230000000694 effects Effects 0.000 claims description 4
- 230000002123 temporal effect Effects 0.000 abstract description 5
- 238000004519 manufacturing process Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 15
- 230000008569 process Effects 0.000 description 12
- 230000002155 anti-virotic effect Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 239000008186 active pharmaceutical agent Substances 0.000 description 4
- 239000003795 chemical substances by application Substances 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000008676 import Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 241000700605 Viruses Species 0.000 description 3
- 230000002265 prevention Effects 0.000 description 3
- 239000004065 semiconductor Substances 0.000 description 3
- 238000000638 solvent extraction Methods 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 239000002184 metal Substances 0.000 description 2
- 229910044991 metal oxide Inorganic materials 0.000 description 2
- 150000004706 metal oxides Chemical class 0.000 description 2
- 230000000116 mitigating effect Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000003542 behavioural effect Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 229920000547 conjugated polymer Polymers 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 238000011982 device technology Methods 0.000 description 1
- 230000005669 field effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 230000001537 neural effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 229920000642 polymer Polymers 0.000 description 1
- 238000004549 pulsed laser deposition Methods 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- ACWBQPMHZXGDFX-QFIPXVFZSA-N valsartan Chemical compound C1=CC(CN(C(=O)CCCC)[C@@H](C(C)C)C(O)=O)=CC=C1C1=CC=CC=C1C1=NN=NN1 ACWBQPMHZXGDFX-QFIPXVFZSA-N 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45545—Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/034—Test or assess a computer or a system
Definitions
- Innovations herein pertain to computer software and hardware, computer virtualization, computer security and/or data isolation, and/or the use of a separation kernel hypervisor (and/or hypervisor), such as to process information including changes to a virtualized hardware environment presented to an operating system and/or to perform other processing regarding fingerprinting attempts by guest software, and which may include or involve guest operating system(s).
- a separation kernel hypervisor and/or hypervisor
- a suitably authorized guest may be allowed to monitor the activities of another guest.
- reasons for such monitoring are debugging and security.
- previous approaches may include various drawbacks, such as allowing guests or guest software to poll memory and other information in other guests or locations and/or attempt to determine if it is running under control of a particular hypervisor or perform other fingerprinting techniques.
- hypervisors may be subverted by malicious code and/or may allow malicious code in a guest operating system to proliferate between a plurality of guest operating systems in the system.
- the Separation Kernel Hypervisor unlike a hypervisor, does not merely support a plurality of Virtual Machines (VMs), but supports more secure, more isolated mechanisms, including systems and mechanisms to monitor and defeat malicious code, where such mechanisms are isolated from the malicious code but are also have high temporal and spatial locality to the malicious code. For example, they are proximate to the malicious code, but incorruptible and unaffected by the malicious code.
- VMs Virtual Machines
- the Separation Kernel Hypervisor is designed and constructed from the ground-up, with security and isolation in mind, in order to provide security and certain isolation between a plurality of software entities (and their associated/assigned resources, e.g., devices, memory, etc.); by mechanisms which may include Guest Operating System Virtual Machine Protection Domains (secure entities established and maintained by a Separation Kernel Hypervisor to provide isolation in time and space between such entities, and subsets therein, which may include guest operating systems, Virtualization Assistance Layers (“VALs”), and VAL mechanisms); where such software entities (and their associated assigned resources, e.g., devices, memory, etc., are themselves isolated and protected from each other by the Separation Kernel Hypervisor, and/or its use of hardware platform virtualization mechanisms.
- Guest Operating System Virtual Machine Protection Domains secure entities established and maintained by a Separation Kernel Hypervisor to provide isolation in time and space between such entities, and subsets therein, which may include guest operating systems, Virtualization Assistance Layers (“VALs”), and VAL
- hypervisors may provide mechanisms to communicate between the hypervisor and antivirus software, or monitoring agent, executing within a guest operating system (for purposes of attempting to monitor malicious code)
- the hypervisor is not able to prevent corruption of the monitoring agent where the agent is within the same guest operating system as the malicious code; or the guest operating system (or any subset thereof, possibly including the antivirus software, and/or monitoring agent) is corrupted and/or subverted.
- a Separation Kernel Hypervisor With a Separation Kernel Hypervisor, one may use a defense-in-depth technique in order to provide a runtime execution environment whereby software can securely monitor for malicious code without being affected or corrupted by it; while at the same time having close proximity (in time and space) to the malicious code (or code, data, and/or resources under monitoring).
- Systems, methods, computer readable media and articles of manufacture consistent with innovations herein are directed to computer virtualization, computer security and/or data isolation, and/or the use of a Separation Kernel Hypervisor (and/or hypervisor), such as by changing the virtualized hardware environment presented to an operating system to prevent attempts to determine if it is running under control of a particular hypervisor or performing other such fingerprinting techniques.
- a Separation Kernel Hypervisor and/or hypervisor
- certain implementations may involve a suitably authorized guest running under control of a hypervisor and involving features of changing the virtualized hardware environment presented to an operating system in various ways.
- innovations herein may utilize and/or involve a separation kernel hypervisor which may include the use of a guest operating system virtual machine protection domain, a virtualization assistance layer, and/or various VAL subcomponents or mechanisms (which may be proximate in temporal and/or spatial locality to malicious code, but isolated from it), inter alia, for varying locations, sizes, results, etc. of various resources or information accessed, queried, or otherwise processed via an operating system or software associated with a guest.
- a separation kernel hypervisor may include the use of a guest operating system virtual machine protection domain, a virtualization assistance layer, and/or various VAL subcomponents or mechanisms (which may be proximate in temporal and/or spatial locality to malicious code, but isolated from it), inter alia, for varying locations, sizes, results, etc. of various resources or information accessed, queried, or otherwise processed via an operating system or software associated with a guest.
- FIG. 1 is a block diagram illustrating an exemplary system and Separation Kernel Hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 2A is a block diagram illustrating an exemplary system and Separation Kernel Hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 2B is a block diagram illustrating an exemplary system and Separation Kernel Hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 3 is a block diagram illustrating an exemplary system and separation kernel Hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 4 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 5 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 6 is a representative sequence diagram illustrating exemplary systems, methods, and Separation Kernel Hypervisor processing/architecture consistent with certain aspects related to the innovations herein.
- FIG. 7 is a representative flow diagram illustrating exemplary systems, methods, and Separation Kernel Hypervisor processing/architecture consistent with certain aspects related to the innovations herein.
- implementations herein may relate to various processing and/or fingerprint prevention techniques, systems, and mechanisms, as may be used with a separation kernel hypervisor.
- such systems and methods may include and/or involve the use of the monitoring and/or changing of the entirety, or suitably configured subset thereof of guest operating system resources including virtualized resources such as the hardware environment and/or “physical” or “pass-through” resources. Examples include changing the virtualized hardware environment presented to an operating system in various ways to prevent attempts to determine if the operating system is running under control (e.g., of a particular hypervisor) via examination of the hardware environment presented to it.
- mechanisms such as a separation kernel hypervisor, a guest operating system virtual machine protection domain, virtual machine assistance layer, and/or virtual hardware presentation mechanisms, may be utilized to perform the processing herein on a corresponding guest operating system.
- Systems and methods are disclosed for varying and/or changing various virtualized hardware environment aspects presented to an operating system and/or guest software and which may include or involve guest operating system(s).
- locations, sizes, results, etc. of various resources or information accessed, queried, or otherwise presented unmodified to an operating system or software associated with a guest may be changed and/or varied.
- processing may also be performed in a timely and expeditious fashion, including by virtue of the modified context being proximate (in time and space) to any unmodified context.
- isolation may be maintained between the operating system and the mechanisms presenting the modified context(s).
- processing may be performed by mechanisms providing a wide and comprehensive set of techniques and resources to an operating system, inter alia, so as to prevent fingerprinting attempts which are multi-lateral and/or multi-dimensional in nature.
- one or more mechanisms within or associated with the VAL may be configured to return results similar to physical hardware devices for configuration queries to virtual devices of the virtualized hardware environment. These mechanisms may be utilized when a monitored guest issues configuration queries regarding devices of the virtualized hardware environment. When software in the monitored guest attempts to issue such queries, control goes to the VAL. Then, the present mechanisms may be implemented to return results similar to those that would be returned for physical hardware devices, for configuration queries to or regarding corresponding virtual devices.
- one or more VAL mechanisms may be configured to vary the location(s) of non-standard, private 110 devices at guest startup time.
- an operating system of a monitored guest may perform various fingerprinting operations, such as those directed to querying the location(s) of non-standard, private I/O devices.
- control goes to the VAL.
- the present mechanisms may be implemented to return results wherein the location(s) of non-standard, private I/O devices that are presented to the operating system are varied.
- Such location information may be varied to cloak information normally revealed by such queries, which may be utilized by operating systems in certain circumstances to determine when the guest is being monitored or under external control.
- one or more VAL mechanisms may be configured to vary the location(s) and/or size(s) of non-standard, private memory areas at guest startup time.
- an operating system on a monitored guest may perform various fingerprinting operations, such as those directed to querying the location(s) and/or size(s) of non-standard, private memory areas.
- control goes to the VAL.
- the present mechanisms may be implemented to return results wherein the location(s) and/or size(s) of non-standard, private memory areas are varied.
- such information may be varied to cloak the information normally revealed by such queries, responses to which may e.g. reveal hypervisor monitoring software.
- one or more mechanisms within or associated with the VAL may be configured to vary the results of execution of CPU identification instructions in the purportedly queried (physical/actual) processor. These mechanisms may be utilized, for example, when a monitored guest executes or issues queries including/regarding CPU identification instructions. When software in the monitored guest issues such instructions, control goes to the VAL. Then, the present mechanisms may be implemented to return varied results of the responses to the CPU identification instructions in the processor according to configuration data for the hypervisor.
- Such operating system and information monitoring may be provided from a context not able to be bypassed, tampered with or corrupted by the context under monitoring.
- monitoring may also be performed in a timely and expeditious fashion, including by virtue of the monitoring context being proximate (in time and space) to the monitored context. Additionally, isolation may be maintained between the monitoring and monitored context.
- monitoring may be performed by mechanisms providing a wide and comprehensive set of monitoring techniques and resources under monitoring, inter alia, so as to monitor against threats which are multi-lateral and/or multi-dimensional in nature.
- systems and methods herein may include and/or involve a virtual machine which is augmented to form a more secure virtual representation (virtualized hardware environment) of the native hardware platform for a particular execution context.
- implementations may also include a virtual representation which is augmented with a wide and deep variety of built-in detection, notification(s) and monitoring mechanisms, and wherein secure isolation between the domains or virtual machines is maintained.
- aspects of the present innovations may include, relate to, and/or involve one or more of the following aspects, features and/or functionality.
- Systems and methods herein may include or involve a separation kernel hypervisor.
- a software entity in hypervisor context that partitions the native hardware platform resources, in time and space, in an isolated and secure fashion may be utilized.
- embodiments may be configured for partitioning/isolation as between a plurality of guest operating system virtual machine protection domains, e.g., entities in a hypervisor guest context.
- the separation kernel hypervisor may host a plurality of guest operating system virtual machine protection domains and may host a plurality of VAL mechanisms such as virtual hardware presentation mechanisms which may execute within such guest operating system virtual machine protection domains. These VAL mechanisms may execute in an environment where guest operating systems cannot tamper with, bypass, or corrupt the mechanisms. The VAL mechanisms may also execute to increase temporal and spatial locality of the guest operating system's resources. Further, in some implementations, the VAL mechanisms may execute in a manner that is not interfered with, nor able to be interfered with, nor corrupted by other guest operating system virtual machine protection domains including their corresponding guest operating systems.
- the VAL mechanisms include, but are not limited to, performing one or more of the following exemplary actions on guest operating systems, including returning results similar to physical hardware results for configuration queries to virtual devices, varying the location(s) of non-standard, private I/O devices at guest startup time, varying the location(s) and/or size(s) of non-standard private memory areas at guest startup time, varying the results of information provided regarding execution of CPU identification instructions in the processor according to configuration data for the hypervisor, etc.
- processing may further include, though is not limited to, actions pertaining to observation, detection, mitigation, prevention, tracking, modification, reporting upon, device access within or by a guest operating system, etc., and/or by entities configured to perform such functions.
- FIG. 1 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 1 also shows a separation kernel hypervisor executing on native hardware platform resources, e.g., where the separation kernel hypervisor may support the execution, isolated and partitioned in time and space, between a plurality of guest operating system protection domains.
- a guest operating system domain may be an entity that is established and maintained by the separation kernel hypervisor in order to provide a secure and isolated execution environment for software.
- a separation kernel hypervisor 100 is shown executing on top of the native hardware platform resources 600 . Further, the separation kernel hypervisor 100 supports the execution of a guest operating system virtual machine protection domain 200 .
- the separation kernel hypervisor 100 may also support the execution of a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 in FIG. 1 .
- the separation kernel hypervisor may provide time and space partitioning in a secure and isolated manner for a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 in FIG. 1 .
- Such features may include rigid guarantees on scheduling resources, execution time, latency requirements, and/or resource access quotas for such domains.
- execution is transitioned to the separation kernel hypervisor 100 .
- the separation kernel hypervisor 100 then creates and executes a guest operating system virtual machine protection domain 200 , or a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 in FIG. 1 .
- Some implementations of doing so consonant with the innovations herein are set forth in PCT Application No. PCT/2012/042330, filed 13 Jun. 2012, published as W02012/177464A1, and U.S. patent application Ser. No. 13/576,155, filed Dec. 12, 2013, published as US2014/0208442A1, which are incorporated herein by reference in entirety.
- a guest operating system may execute.
- VAL mechanisms may also execute, e.g., in a fashion isolated from any guest operating system which may also execute within that same guest operating system virtual machine protection domain, or in other guest operating system virtual machine protection domains.
- FIG. 2A is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 2A also shows a separation kernel hypervisor 100 executing on native hardware platform resources (where the native platform resources may include a plurality of CPUs, buses and interconnects, main memory, Network Interface Cards (NIC), Hard Disk Drives (HDD), Solid State Drives (SSD), Graphics Adaptors, Audio Devices, Mouse/Keyboard/Pointing Devices, Serial I/O, USB, and/or Raid Controllers, etc.), where the separation kernel hypervisor may support the execution, isolated and/or partitioning in time and space, between a plurality of guest operating system protection domains.
- NIC Network Interface Cards
- HDD Hard Disk Drives
- SSD Solid State Drives
- the separation kernel hypervisor may support the execution, isolated and/or partitioning in time and space, between a plurality of guest operating system protection domains.
- some implementations may involve a guest operating system protection domains which may contain a guest operating system, and/or a virtualization assistance layer 400 or 499 (which, themselves, may contain VAL mechanisms, 500 , or 597 . 598 , 599 , respectively).
- the separation kernel hypervisor 100 may include, access and/or involve various CPU identification instruction virtualization mechanisms, provided for the purpose of varying results returned to a monitored guest responsive to queries or other requests for CPU identification instructions.
- such mechanism may include reporting a CPU model, stepping, clock speed, or other configuration information that is configurable, rather than reporting a single, unchanging value, or the actual value from the physical CPU.
- the separation kernel hypervisors shown in the later drawings of the present inventions do not explicitly show this subcomponent, it is hereby noted that such implementations may include, access or otherwise involve such subcomponent or mechanisms, as well.
- FIG. 2A shows both a guest operating system 300 , and a virtualization assistance layer 400 executing within the same guest operating system virtual machine protection domain 200 .
- the virtualization assistance layer 400 may provide the execution environment for the memory access VAL mechanisms 500 (also 597 , 598 , 599 ; hereinafter, together, “VAL mechanisms”).
- the virtualization assistance layer 400 may assist the separation kernel hypervisor in virtualizing portions of the platform resources exported to a given guest operating system (e.g., Virtual CPU/ABI, Virtual chipset ABI, set of virtual devices, set of physical devices, and/or firmware, etc., assigned to a given guest operating system 300 and/or guest virtual machine protection domain 200 ).
- Some systems and methods herein utilizing such virtualization assistance layer may include or involve (but are not strictly limited to) a self-assisted virtualization component, e.g., with an illustrative implementation shown in FIG. 2B .
- a monitored guest operating system 300 may include guest operating system virtualization probing code (discussed in more detail in connection with FIG. 8 , below) that may be malicious code installed for purposes of fingerprinting or otherwise probing or determining if the operating system is running under control of a particular hypervisor by examining the hardware environment presented to it.
- guest operating system virtualization probing code discussed in more detail in connection with FIG. 8 , below
- the guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500 ) are isolated from each other by the separation kernel hypervisor 100 .
- the guest operating system 300 cannot tamper with, bypass, or corrupt the virtualization assistance layer 400 , nor can it tamper with, bypass or corrupt the VAL mechanisms 500 .
- the VAL mechanisms 500 are isolated from the guest operating system 300 , the VAL mechanisms 500 are able to act on a portion of (or the entirety, depending on policy and configuration) of the guest operating system 300 and its assigned resources in a manner that is (a) is transparent to the guest operating system 300 and (b) not able to be tampered with by the guest operating system 300 or its assigned resources (e.g., errant and/or malicious device DMA originated by devices assigned to the guest operating system 300 ), and (c) not able to be bypassed by the guest operating system 300 .
- the VAL mechanisms 500 within the given virtualization assistance layer 400 , may read and/or modify portions of the guest operating system 300 and resources to which the Guest Operating System 300 has been granted access (by the Separation Kernel Hypervisor 100 ), while none of the Guest Operating System 300 nor the resources to which has access may modify any portion of the VAL mechanisms 500 and/or virtualization assistance layer 400 .
- the virtualization assistance layer 200 By being contained within the same Guest Virtual Machine Protection Domain 300 , the virtualization assistance layer 200 , and/or corresponding private (local) VAL mechanisms 500 existing in that same Guest Virtual Machine Protection Domain 300 , have greater access, such as in time and space, to the resources of the Guest Operating System 300 than would entities in other guest virtual machine protection domains or other Guest Operating Systems; e.g., the subject guest virtual machine protection domain has faster responsiveness and/or has lower latency than if processed in another guest virtual machine protection domain. Though such resources are still accessed in a manner that is ultimately constrained by the Separation Kernel Hypervisor 100 , there is less indirection and time/latency consumed in accessing the resources:
- the VAL mechanisms 500 private (local) to a given Guest virtualization assistance layer 200 and its associated Guest Operating System 300 can react faster to physical memory access issues, and not need to wait on actions from another entity in another guest virtual machine protection domain 200 or guest operating system 300 (which may themselves have high latency, be corrupted, unavailable, poorly scheduled, or subject to a lack of determinism and/or resource constraint, or improper policy configuration, etc.).
- a Guest Operating System 300 was to monitor a Guest Operating System 399 located within another Guest Virtual Machine Protection Domain 107 , it would encounter penalties in time and space for accessing that Guest Operating System and its resources; furthermore, there is increased code, data, scheduling, and/or security policy complexity to establish and maintain such a more complex system; such increases in complexity and resources allow for more bugs in the implementation, configuration, and/or security policy establishment and maintenance.
- Each Guest Operating System 300 may have a virtualization assistance layer 200 , and VAL mechanisms 500 , that are private (local) to the Guest Virtual Machine Protection Domain 200 that contains both that Guest Operating System 300 , the virtualization assistance layer 400 , and the VAL mechanisms.
- the virtualization assistance layer 400 , the VAL mechanism 500 , and the Guest Operating System 300 within the same Guest Virtual Machine Protection Domain 200 are only able to act on portions of that Guest Virtual Machine Protection Domain 200 (subject to the Separation Kernel Hypervisor 100 ) and not portions of other Guest Virtual Machine Protection Domains (nor their contained or assigned resources).
- the virtualization assistance layer 400 accesses only the resources of the Guest Operating System 300 within the same Guest Virtual Machine Protection Domain 200 and that virtualization assistance layer 400 is not able to access the resources of other Guest Operating Systems.
- Separation Kernel Hypervisor to act upon (e.g., instantiate, maintain, monitor, create/destroy, suspend, restart, refresh, backup/restore, patch/fix, import/export etc.) a plurality of Guest Virtual Machine Protection Domains 200 and their corresponding virtualization assistance layer 400 and VAL mechanisms 500 (or even Guest Operating Systems 300 ) without corruption of the most privileged execution context of the system, the Separation Kernel Hypervisor 100 .
- the faults that may occur within a virtualization assistance layer 400 or the VAL mechanisms 500 are contained to the Guest Virtual Machine Protection Domain 200 and do not corrupt any other Guest Virtual Machine Protection Domain; nor do they corrupt the Separation Kernel Hypervisor 100 .
- the faults within a Guest Operating System 300 are contained to that Guest Operating System 300 , and do not corrupt either the virtualization assistance layer 400 or the VAL mechanisms 500 .
- FIG. 2B is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 2B illustrates a variation of FIG. 2A where a minimal runtime environment 398 executes in place of a (larger/more complex) guest operating system, within the virtual machine protection domain 298 .
- a minimal runtime environment may be an environment such as a VDS (virtual device server), and/or a LSA (LynxSecure application), etc.
- the minimal runtime environment 398 can be used for policy enforcement related to activities reported by a virtualization assistance layer and/or instruction execution detection/interception mechanisms; such an environment is also monitored by a virtualization assistance layer and/or instruction execution detection/interception mechanisms private to the guest operating system virtual machine protection domain containing the minimal runtime environment.
- Various virtual resources or subcomponents 598 belong and are private to the VAL 498 of the guest operating system 398 , and are protected from and invisible to the guest.
- such virtual resources 598 may include one or more of virtual devices 597 , VAL internal I/O addresses 598 , and/or VAL internal memory regions 599 .
- FIG. 3 is a block diagram illustrating an exemplary system and separation kernel Hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 3 also shows certain detailed aspects with respect to FIG. 2A etc, where the guest operating system may attempt to query devices or resources such as by including a plurality of code and/or data which may constitute execution contexts which may include the following types of software including any/all of which malicious code may attempt to corrupt or utilize: malicious code, anti-virus software, corrupted anti-virus software, integrity checkers, corrupted integrity checkers, rootkits, return oriented rootkits, etc.
- the invention is not limited to memory access attempts by malicious code and is discussed below via illustrative examples.
- the corruption is constrained to the given guest operating system 300 , and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or via VAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtual machine protection domain 200 as the guest operating system 300 .
- an integrity checker 2003 e.g., a “security” component or driver within a guest operating system 300 .
- the corruption is constrained to the given guest operating system 300 , and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by various mechanisms within the VAL.
- a rootkit 2006 executes within the guest operating system 300 (e.g., by having fooled the Integrity Checker 2003 by the nature of the root kit being a return oriented rootkit 2007 , which are designed specifically to defeat integrity checkers) the corruption is constrained to the given guest operating system 300 , and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or via VAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtual machine protection domain 200 as the guest operating system 300 .
- a polymorphic virus 2005 an entity designed to defeat integrity checkers, among other things
- the corruption is constrained to the given guest operating system 300 , and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or via VAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtual machine protection domain 200 as the guest operating system 300 .
- a malicious code 2000 executes within the guest operating system 300 (e.g., by means including, but not limited strictly to bugs, defects, bad patches, code and/or data corruption, failed integrity checkers, poor security policy, root kits, viruses, trojans, polymorphic viruses, and/or other attack vectors and/or sources of instability within the guest operating system 300 etc.)
- the corruption is constrained to the given guest operating system 300 , and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or via VAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtual machine protection domain 200 as the guest operating system 300 .
- such corruption of the guest operating system 300 , and the resources to which it has access do not corrupt the VAL mechanisms 500 or other mechanisms within the VAL, the virtualization assistance layer 400 , the guest virtual machine protection domain 200 , or plurality of other such resources in the system (e.g., other guest virtual machine protection domains 299 ), or the separation kernel hypervisor 100 .
- the VAL mechanisms 500 in conjunction with the virtualization assistance layer 400 , and the separation kernel hypervisor 100 , may utilize various methods and mechanisms such as the following, given by way of illustration and example but not limitation, to act with and upon its associated guest operating system 300 the resources assigned to the guest operating system 300 , and the systems behavior generated thereto and/or thereby.
- FIG. 4 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 4 illustrates resources that may be assigned to a Guest Operating System 300 consistent with certain aspects related to the innovations herein.
- FIG. 4 shows an illustrative extension of either FIG. 2 , and/or FIG. 3 , where the guest operating system may have a plurality of code and/or data which may constitute execution contexts which may include the following types of software mechanisms and/or constructs user space code and data that may be associated with an unprivileged mode of CPU Malware execution (as used herein ‘user space’ being an execution environment of low privilege, versus an execution environment of high privilege, such as kernel space), which may contain processes, tasks, and/or threads, etc.; kernel space code and data, that may be associated with a privileged mode of CPU execution, which may contain tasks, threads, interrupt handlers, drivers, etc.; shared code and data, that may be associated with either privileged and/or unprivileged modes of CPU execution, and which may include signal handlers, Inter Process Communication Mechanisms (IPC), and/or user/kernel mode APIs.
- IPC Inter Process Communication Mechanisms
- VAL mechanisms 500 , 597 , 598 , 599 may reside within corresponding Virtualization Assistance Layers 400 , 499
- Such resources may include a subset of (a) hardware platform resources 600 , virtualized hardware platform resources (hardware platform resources 600 subject to further constraint by the separation kernel hypervisor 100 , the hardware CPU virtualization protection mechanisms 602 , and/or the hardware virtualization DMA protection mechanisms 601 ), and execution time on a CPU 700 (or a plurality of CPUs, e.g., 700 to 731 ) (scheduling time provided by the separation kernel hypervisor 100 ), and space (memory 900 provided by the separation kernel hypervisor) within which the guest operating system 300 may instantiate and utilize constructs of the particular guest operating system 300 , such as a privileged (“kernel” space) modes of execution, non-privileged (“user” space) modes of execution, code and data for each such mode of execution (e.g., processes, tasks, threads, interrupt handlers, drivers, signal handlers, inter process communication mechanisms, shared memory, shared APIs between such entities/contexts/modes, etc.
- FIG. 5 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.
- FIG. 5 shows an illustrative implementation as may be associated with FIG. 2 , FIG. 3 , and/or FIG. 4 , where various VAL mechanisms, which may be within the virtualization assistance layer, may include the various monitoring and presentation mechanisms such as query monitor(s), instruction monitor(s), virtual hardware/device presentation mechanisms, etc.
- FIG. 5 shows an illustrative implementation as may be associated with FIG. 2 , FIG. 3 , and/or FIG. 4 , where various VAL mechanisms, which may be within the virtualization assistance layer, may include the various monitoring and presentation mechanisms such as query monitor(s), instruction monitor(s), virtual hardware/device presentation mechanisms, etc.
- FIG. 5 shows an illustrative implementation as may be associated with FIG. 2 , FIG. 3 , and/or FIG. 4 , where various VAL mechanisms, which may be within the virtualization assistance layer, may include the various monitoring and presentation
- FIG. 5 also illustrates an import/export mechanism that may be used by a virtualization assistance layer and/or VAL mechanisms to communicate between themselves and other virtualization assistance layer and/or VAL mechanisms in other guest operating system virtual machine protection domains (subject to the security policies established, maintained, and enforced by the separation kernel hypervisor), in an isolated, secure, and even monitored fashion.
- FIG. 5 illustrates mechanism and resources that may be used by the VAL mechanisms 500 to monitor a guest operating system 300 .
- Such mechanisms and resources may include a memory monitor 501 and an instruction monitor 502 .
- the virtualization assistance layer 400 and/or the VAL mechanisms 500 may also use an export API 509 and/or an import API 599 (as may be configured and governed by the separation kernel hypervisor 100 ), in order to provide secure communication between a plurality of virtualization assistance layers (e.g., virtualization assistance layers 400 to 499 ) and/or a plurality of VAL mechanisms (e.g., VAL mechanisms 500 to 599 ).
- a plurality of virtualization assistance layers e.g., virtualization assistance layers 400 to 499
- a plurality of VAL mechanisms e.g., VAL mechanisms 500 to 599 .
- Systems and mechanisms, and example embodiments, of the VAL mechanisms 500 may include:
- the separation kernel hypervisor 100 may trap and perform the processing herein regarding access to such device(s), and then pass associated data regarding that trap to the virtualization assistance layer 400 .
- the virtualization assistance layer 400 may then pass the associated data of that trap to the VAL mechanisms 500 .
- the monitoring of guest operating system 300 virtual device access includes, but is not limited to, constructs in guest operating system 300 devices which may have semantics specific to a specific hardware architecture. For example, a virtualized Network Interface, a virtualized disk controller, or a virtualized interrupt controller, any of which may be probed by guest software intent on determining if it is running under a hypervisor.
- the monitoring of guest operating system 300 device access includes, but is not limited to, constructs in guest operating system 300 devices (including the resources shown in FIGS. 3 and 4 ) which may have semantics specific to the implementation of a particular separation kernel hypervisor.
- the Separation Kernel Hypervisor 100 may trap such access attempts, then pass associated data of that trap to the virtualization assistance layer 400 and/or VAL mechanisms 500 .
- FIGS. 6 and 7 are representative sequence/flow diagrams illustrating exemplary systems, methods, and Separation Kernel Hypervisor processing/architecture consistent with certain aspects related to the innovations herein.
- FIGS. 6 and 7 relate, inter alia, to the guest operating system attempting to perform various fingerprinting operations such as: query or perform other processing in connection with virtual devices, perform processing in connection with non-standard, private I/O devices or memory areas at guest startup time, execute or otherwise process data in connection with the issuance of CPU identification instructions, etc.
- a Guest Operating System 300 processes a request related to virtualization probing code, such as configuration and/or identification queries pertaining to the virtual hardware environment.
- the request is sent to the Separation Kernel Hypervisor SKH 100 .
- the SKH 100 ensures the isolation of multiple guest Operating Systems each in its own Virtual Machine (VM) (step i).
- the SKH 100 transitions execution to the Virtualization Assistance Layer 400 .
- the SKH 100 processes instructions to execute a Virtualization Assistance Layer 400 that runs within the same protection domain as the Guest Virtual Machine, but which is not directly accessible by the guest (step ii).
- the VAL 400 may vary the location of non-standard, private I/O devices (step v) and/or vary the location and size of non-standard, private memory areas (step vi). Then, at 840 , the VAL 400 may implement the virtual devices 500 , e.g., a virtual motherboard including at least one virtual device such as a virtual CPU, a disk controller, a USB controller, keyboard, mouse and serial interface(s) (step iii). Next, for configuration queries to the virtual devices 500 at step (iv), the VAL returns results similar to physical hardware after transitioning execution from virtual devices 500 to VAL 400 , at 845 . Next, at step 825 the virtualization assistance layer transitions execution back to the Separation Kernel Hypervisor, or the Separation Kernel Hypervisor transitions execution from the virtualization assistance layer back to the Separation Kernel Hypervisor.
- the virtualization assistance layer transitions execution back to the Separation Kernel Hypervisor, or the Separation Kernel Hypervisor transitions execution from the virtualization assistance layer
- the SKH 100 transitions execution to a CPU Instruction Handler 101 that varies the results of execution of the CPU identification instructions in the processor according to configuration data for the hypervisor (step vii).
- the results of the CPU identification instruction handler 101 is returned to the SKH 100 . Further, in order to change the virtualized hardware environment presented to an operation system in various ways to prevent “fingerprinting”, execution may cycle a multiple times between steps 805 through 845 .
- the virtual machine platform presented to a guest in a hypervisor may be varied, or presented to such operating system in a specified manner, in order to prevent software running in the guest from discovering that it is being run under control of the hypervisor.
- a Separation Kernel Hypervisor ensures the isolation of multiple guest Operating Systems each in its own Virtual Machine (VM).
- VM Virtual Machine
- a Virtualization Assistance Layer of software is implemented, at 910 , which runs within the same protection domain as the guest Virtual Machine, but is not directly accessible by the guest.
- the virtualization assistance layer then implements, at 915 , a virtual motherboard containing a virtual CPU and virtual devices such as disk controllers, USB controllers, keyboard, mouse, and serial interfaces.
- the VAL may vary the location of non-standard, private I/O devices, at 935 , and/or the VAL may vary the location and/or size of non-standard, private memory areas, at 940 .
- Processing then proceeds to a virtual hardware presentation phase 960 , wherein one or more of a variety of virtual hardware presentation mechanisms and/or VAL mechanisms may optionally be included and/or utilized responsive to queries, instructions or other processing attempts from a monitored guest.
- a configuration query may be received regarding virtual device(s).
- the VAL may then return results similar to physical hardware, at 925 .
- the hypervisor may vary the results of execution of CPU identification instructions in the processor according to configuration data for the hypervisor, at 950 . Additional operations from the VAL may also be performed. After such operations and/or processing is performed, execution may then be transitioned back to the VAL, at 970 .
- innovations and mechanisms herein may also provide or enable means by which software that attempts to detect that it is running under a hypervisor in order to prevent its detection by malware protection software, or otherwise change its behavior will instead run as it would without the hypervisor.
- the innovations herein may be implemented via one or more components, systems, servers, appliances, other subcomponents, or distributed between such elements.
- system When implemented as a system, such system may comprise, inter alia, components such as software modules, general-purpose CPU, RAM, etc. found in general-purpose computers, and/or FPGAs and/or ASICs found in more specialized computing devices.
- a server may comprise components such as CPU, RAM, etc. found in general-purpose computers.
- innovations herein may be achieved via implementations with disparate or entirely different software, hardware and/or firmware components, beyond that set forth above.
- components e.g., software, processing components, etc.
- computer-readable media associated with or embodying the present inventions
- aspects of the innovations herein may be implemented consistent with numerous general purpose or special purpose computing systems or configurations.
- exemplary computing systems, environments, and/or configurations may include, but are not limited to: software or other components within or embodied on personal computers, appliances, servers or server computing devices such as routing/connectivity components, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, consumer electronic devices, network PCs, other existing computer platforms, distributed computing environments that include one or more of the above systems or devices, etc.
- aspects of the innovations herein may be achieved via logic and/or logic instructions including program modules, executed in association with such components or circuitry, for example.
- program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein.
- the inventions may also be practiced in the context of distributed circuit settings where circuitry is connected via communication buses, circuitry or links. In distributed settings, control/instructions may occur from both local and remote computer storage media including memory storage devices.
- Computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and/or computing components.
- Computer readable media may comprise computer storage media and other non-transitory media.
- Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
- Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and can accessed by computing component.
- Other non-transitory media may comprise computer readable instructions, data structures, program modules or other data embodying the functionality herein, in various non-transitory formats. Combinations of the any of the above are also included within the scope of computer readable media.
- the terms component, module, device, etc. may refer to any type of logical or functional circuits, blocks and/or processes that may be implemented in a variety of ways.
- the functions of various circuits and/or blocks can be combined with one another into any other number of modules.
- Each module may even be implemented as a software program stored on a tangible memory (e.g., random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be read by a central processing unit to implement the functions of the innovations herein.
- the modules can comprise programming instructions transmitted to a general purpose computer, to processing/graphics hardware, and the like.
- the modules can be implemented as hardware logic circuitry implementing the functions encompassed by the innovations herein.
- the modules can be implemented using special purpose instructions (SIMD instructions), field programmable logic arrays or any mix thereof which provides the desired level performance and cost.
- SIMD instructions special purpose instructions
- features consistent with the present inventions may be implemented via computer-hardware, software and/or firmware.
- the systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them.
- a data processor such as a computer that also includes a database
- digital electronic circuitry such as a computer
- firmware such as a firmware
- software such as a computer that also includes a database
- digital electronic circuitry such as a computer that also includes a database
- firmware firmware
- software software
- Such environments and related applications may be specially constructed for performing the various routines, processes and/or operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality.
- the processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware.
- various general-purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.
- aspects of the method and system described herein, such as the logic may also be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (“PLDs”), such as field programmable gate arrays (“FPGAs”), programmable array logic (“PAL”) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits.
- PLDs programmable logic devices
- FPGAs field programmable gate arrays
- PAL programmable array logic
- Some other possibilities for implementing aspects include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc.
- aspects may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types.
- the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (“MOSFET”) technologies like complementary metal-oxide semiconductor (“CMOS”), bipolar technologies like emitter-coupled logic (“ECL”), polymer technologies (e.g., Silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, and so on.
- MOSFET metal-oxide semiconductor field-effect transistor
- CMOS complementary metal-oxide semiconductor
- ECL emitter-coupled logic
- polymer technologies e.g., Silicon-conjugated polymer and metal-conjugated polymer-metal structures
- mixed analog and digital and so on.
- the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
Abstract
Description
- This is a continuation of application Ser. No. 15/396,231, filed Dec. 30, 2016, now U.S. Pat. No. 10,824,715, which is a (bypass) continuation of PCT patent application No. PCT/US2015/038918, international filing date Jul. 1, 2015, published as WO2016/004263, and which claims benefit/priority of provisional application No. 62/019,818, filed Jul. 1, 2014, all of which are incorporated herein by reference in entirety.
- Innovations herein pertain to computer software and hardware, computer virtualization, computer security and/or data isolation, and/or the use of a separation kernel hypervisor (and/or hypervisor), such as to process information including changes to a virtualized hardware environment presented to an operating system and/or to perform other processing regarding fingerprinting attempts by guest software, and which may include or involve guest operating system(s).
- In computer systems with hypervisors supporting a guest operating system, there exist some means to monitor the guest operating system for malicious or errant activity.
- In a virtualized environment, running under control of a hypervisor, a suitably authorized guest may be allowed to monitor the activities of another guest. Among the reasons for such monitoring are debugging and security. However, previous approaches may include various drawbacks, such as allowing guests or guest software to poll memory and other information in other guests or locations and/or attempt to determine if it is running under control of a particular hypervisor or perform other fingerprinting techniques.
- However, due to the constantly evolving nature of malicious code, such systems face numerous limitations in their ability to detect and defeat malicious code. One major limitation is the inability of a hypervisor to defend itself against malicious code; e.g., the particular hypervisor may be subverted by malicious code and/or may allow malicious code in a guest operating system to proliferate between a plurality of guest operating systems in the system.
- To solve that issue, the motivation and use of a Separation Kernel Hypervisor is introduced in environments with malicious code. The Separation Kernel Hypervisor, unlike a hypervisor, does not merely support a plurality of Virtual Machines (VMs), but supports more secure, more isolated mechanisms, including systems and mechanisms to monitor and defeat malicious code, where such mechanisms are isolated from the malicious code but are also have high temporal and spatial locality to the malicious code. For example, they are proximate to the malicious code, but incorruptible and unaffected by the malicious code.
- Furthermore the Separation Kernel Hypervisor is designed and constructed from the ground-up, with security and isolation in mind, in order to provide security and certain isolation between a plurality of software entities (and their associated/assigned resources, e.g., devices, memory, etc.); by mechanisms which may include Guest Operating System Virtual Machine Protection Domains (secure entities established and maintained by a Separation Kernel Hypervisor to provide isolation in time and space between such entities, and subsets therein, which may include guest operating systems, Virtualization Assistance Layers (“VALs”), and VAL mechanisms); where such software entities (and their associated assigned resources, e.g., devices, memory, etc., are themselves isolated and protected from each other by the Separation Kernel Hypervisor, and/or its use of hardware platform virtualization mechanisms.
- Additionally, where some hypervisors may provide mechanisms to communicate between the hypervisor and antivirus software, or monitoring agent, executing within a guest operating system (for purposes of attempting to monitor malicious code), the hypervisor is not able to prevent corruption of the monitoring agent where the agent is within the same guest operating system as the malicious code; or the guest operating system (or any subset thereof, possibly including the antivirus software, and/or monitoring agent) is corrupted and/or subverted.
- With a Separation Kernel Hypervisor, one may use a defense-in-depth technique in order to provide a runtime execution environment whereby software can securely monitor for malicious code without being affected or corrupted by it; while at the same time having close proximity (in time and space) to the malicious code (or code, data, and/or resources under monitoring).
- Finally, while some known systems and methods include implementations involving virtualized assistance layers and separation kernel hypervisors to handle various malicious code intrusions, such systems and method possess limitations and/or restrictions with regard to handling and/or intercepting certain specified attacks, such as those related to fingerprinting or other such probing code attempts.
- Overview of Some Aspects
- Systems, methods, computer readable media and articles of manufacture consistent with innovations herein are directed to computer virtualization, computer security and/or data isolation, and/or the use of a Separation Kernel Hypervisor (and/or hypervisor), such as by changing the virtualized hardware environment presented to an operating system to prevent attempts to determine if it is running under control of a particular hypervisor or performing other such fingerprinting techniques. Here, for example, certain implementations may involve a suitably authorized guest running under control of a hypervisor and involving features of changing the virtualized hardware environment presented to an operating system in various ways.
- According to some illustrative implementations, innovations herein may utilize and/or involve a separation kernel hypervisor which may include the use of a guest operating system virtual machine protection domain, a virtualization assistance layer, and/or various VAL subcomponents or mechanisms (which may be proximate in temporal and/or spatial locality to malicious code, but isolated from it), inter alia, for varying locations, sizes, results, etc. of various resources or information accessed, queried, or otherwise processed via an operating system or software associated with a guest.
- It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the inventions, as described. Further features and/or variations may be provided in addition to those set forth herein. For example, the present inventions may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed below in the detailed description.
- The accompanying drawings, which constitute a part of this specification, illustrate various implementations and features of the present innovations and, together with the description, explain aspects of the inventions herein. In the drawings:
-
FIG. 1 is a block diagram illustrating an exemplary system and Separation Kernel Hypervisor architecture consistent with certain aspects related to the innovations herein. -
FIG. 2A is a block diagram illustrating an exemplary system and Separation Kernel Hypervisor architecture consistent with certain aspects related to the innovations herein. -
FIG. 2B is a block diagram illustrating an exemplary system and Separation Kernel Hypervisor architecture consistent with certain aspects related to the innovations herein. -
FIG. 3 is a block diagram illustrating an exemplary system and separation kernel Hypervisor architecture consistent with certain aspects related to the innovations herein. -
FIG. 4 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein. -
FIG. 5 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein. -
FIG. 6 is a representative sequence diagram illustrating exemplary systems, methods, and Separation Kernel Hypervisor processing/architecture consistent with certain aspects related to the innovations herein. -
FIG. 7 is a representative flow diagram illustrating exemplary systems, methods, and Separation Kernel Hypervisor processing/architecture consistent with certain aspects related to the innovations herein. - Reference will now be made in detail to the inventions herein, examples of which are illustrated in the accompanying drawings. The implementations set forth in the following description do not represent all implementations consistent with the inventions herein. Instead, they are merely some examples consistent with certain aspects related to the present innovations. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts.
- To solve one or more of the shortcomings mentioned above and/or other drawbacks, implementations herein may relate to various processing and/or fingerprint prevention techniques, systems, and mechanisms, as may be used with a separation kernel hypervisor. Among other things, such systems and methods may include and/or involve the use of the monitoring and/or changing of the entirety, or suitably configured subset thereof of guest operating system resources including virtualized resources such as the hardware environment and/or “physical” or “pass-through” resources. Examples include changing the virtualized hardware environment presented to an operating system in various ways to prevent attempts to determine if the operating system is running under control (e.g., of a particular hypervisor) via examination of the hardware environment presented to it.
- With regard to certain implementations, in order to perform such advanced fingerprint prevention in a manner that maintains suitable performance characteristics in a system that may include a separation kernel hypervisor and a guest operating system, mechanisms such as a separation kernel hypervisor, a guest operating system virtual machine protection domain, virtual machine assistance layer, and/or virtual hardware presentation mechanisms, may be utilized to perform the processing herein on a corresponding guest operating system.
- Systems and methods are disclosed for varying and/or changing various virtualized hardware environment aspects presented to an operating system and/or guest software and which may include or involve guest operating system(s). According to some implementations, for example, locations, sizes, results, etc. of various resources or information accessed, queried, or otherwise presented unmodified to an operating system or software associated with a guest may be changed and/or varied. Here, such processing may also be performed in a timely and expeditious fashion, including by virtue of the modified context being proximate (in time and space) to any unmodified context. Additionally, isolation may be maintained between the operating system and the mechanisms presenting the modified context(s). Further, such processing may be performed by mechanisms providing a wide and comprehensive set of techniques and resources to an operating system, inter alia, so as to prevent fingerprinting attempts which are multi-lateral and/or multi-dimensional in nature.
- According to some implementations, for example, one or more mechanisms within or associated with the VAL may be configured to return results similar to physical hardware devices for configuration queries to virtual devices of the virtualized hardware environment. These mechanisms may be utilized when a monitored guest issues configuration queries regarding devices of the virtualized hardware environment. When software in the monitored guest attempts to issue such queries, control goes to the VAL. Then, the present mechanisms may be implemented to return results similar to those that would be returned for physical hardware devices, for configuration queries to or regarding corresponding virtual devices.
- According to some or other implementations, one or more VAL mechanisms may be configured to vary the location(s) of non-standard, private 110 devices at guest startup time. Here, for example, an operating system of a monitored guest may perform various fingerprinting operations, such as those directed to querying the location(s) of non-standard, private I/O devices. When software in the monitored guest attempts to issue such queries, control goes to the VAL. Then, the present mechanisms may be implemented to return results wherein the location(s) of non-standard, private I/O devices that are presented to the operating system are varied. Such location information may be varied to cloak information normally revealed by such queries, which may be utilized by operating systems in certain circumstances to determine when the guest is being monitored or under external control.
- According to some or other implementations, one or more VAL mechanisms may be configured to vary the location(s) and/or size(s) of non-standard, private memory areas at guest startup time. Here, for example, an operating system on a monitored guest may perform various fingerprinting operations, such as those directed to querying the location(s) and/or size(s) of non-standard, private memory areas. When software in the monitored guest attempts to issue such queries, control goes to the VAL. Then, the present mechanisms may be implemented to return results wherein the location(s) and/or size(s) of non-standard, private memory areas are varied. As with above, such information may be varied to cloak the information normally revealed by such queries, responses to which may e.g. reveal hypervisor monitoring software.
- According to some or other implementations, one or more mechanisms within or associated with the VAL may be configured to vary the results of execution of CPU identification instructions in the purportedly queried (physical/actual) processor. These mechanisms may be utilized, for example, when a monitored guest executes or issues queries including/regarding CPU identification instructions. When software in the monitored guest issues such instructions, control goes to the VAL. Then, the present mechanisms may be implemented to return varied results of the responses to the CPU identification instructions in the processor according to configuration data for the hypervisor.
- Systems and methods are disclosed for providing secure operating system and information monitoring. According to some implementations, for example, such operating system and information monitoring may be provided from a context not able to be bypassed, tampered with or corrupted by the context under monitoring. Here, monitoring may also be performed in a timely and expeditious fashion, including by virtue of the monitoring context being proximate (in time and space) to the monitored context. Additionally, isolation may be maintained between the monitoring and monitored context. Further, such monitoring may be performed by mechanisms providing a wide and comprehensive set of monitoring techniques and resources under monitoring, inter alia, so as to monitor against threats which are multi-lateral and/or multi-dimensional in nature.
- Moreover, systems and methods herein may include and/or involve a virtual machine which is augmented to form a more secure virtual representation (virtualized hardware environment) of the native hardware platform for a particular execution context. And such implementations may also include a virtual representation which is augmented with a wide and deep variety of built-in detection, notification(s) and monitoring mechanisms, and wherein secure isolation between the domains or virtual machines is maintained.
- In general, aspects of the present innovations may include, relate to, and/or involve one or more of the following aspects, features and/or functionality. Systems and methods herein may include or involve a separation kernel hypervisor. According to some implementations, a software entity in hypervisor context that partitions the native hardware platform resources, in time and space, in an isolated and secure fashion may be utilized. Here, for example, embodiments may be configured for partitioning/isolation as between a plurality of guest operating system virtual machine protection domains, e.g., entities in a hypervisor guest context.
- The separation kernel hypervisor may host a plurality of guest operating system virtual machine protection domains and may host a plurality of VAL mechanisms such as virtual hardware presentation mechanisms which may execute within such guest operating system virtual machine protection domains. These VAL mechanisms may execute in an environment where guest operating systems cannot tamper with, bypass, or corrupt the mechanisms. The VAL mechanisms may also execute to increase temporal and spatial locality of the guest operating system's resources. Further, in some implementations, the VAL mechanisms may execute in a manner that is not interfered with, nor able to be interfered with, nor corrupted by other guest operating system virtual machine protection domains including their corresponding guest operating systems. The VAL mechanisms include, but are not limited to, performing one or more of the following exemplary actions on guest operating systems, including returning results similar to physical hardware results for configuration queries to virtual devices, varying the location(s) of non-standard, private I/O devices at guest startup time, varying the location(s) and/or size(s) of non-standard private memory areas at guest startup time, varying the results of information provided regarding execution of CPU identification instructions in the processor according to configuration data for the hypervisor, etc.
- Where such processing may further include, though is not limited to, actions pertaining to observation, detection, mitigation, prevention, tracking, modification, reporting upon, device access within or by a guest operating system, etc., and/or by entities configured to perform such functions.
-
FIG. 1 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.FIG. 1 also shows a separation kernel hypervisor executing on native hardware platform resources, e.g., where the separation kernel hypervisor may support the execution, isolated and partitioned in time and space, between a plurality of guest operating system protection domains. Here, a guest operating system domain may be an entity that is established and maintained by the separation kernel hypervisor in order to provide a secure and isolated execution environment for software. Referring toFIG. 1 , aseparation kernel hypervisor 100 is shown executing on top of the nativehardware platform resources 600. Further, theseparation kernel hypervisor 100 supports the execution of a guest operating system virtualmachine protection domain 200. - The
separation kernel hypervisor 100 may also support the execution of a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 inFIG. 1 . In some implementations, the separation kernel hypervisor may provide time and space partitioning in a secure and isolated manner for a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 inFIG. 1 . Such features may include rigid guarantees on scheduling resources, execution time, latency requirements, and/or resource access quotas for such domains. - According to some implementations, in terms of the sequence of establishment, after the native
hardware platform resources 600 boot the system, execution is transitioned to theseparation kernel hypervisor 100. Theseparation kernel hypervisor 100 then creates and executes a guest operating system virtualmachine protection domain 200, or a plurality of guest operating system virtual machine protection domains, e.g., 200 to 299 inFIG. 1 . Some implementations of doing so consonant with the innovations herein are set forth in PCT Application No. PCT/2012/042330, filed 13 Jun. 2012, published as W02012/177464A1, and U.S. patent application Ser. No. 13/576,155, filed Dec. 12, 2013, published as US2014/0208442A1, which are incorporated herein by reference in entirety. - Consistent with aspects of the present implementations, it is within a guest operating system virtual machine protection domain that a guest operating system may execute. Further, it is within a guest operating system virtual machine protection domain that VAL mechanisms may also execute, e.g., in a fashion isolated from any guest operating system which may also execute within that same guest operating system virtual machine protection domain, or in other guest operating system virtual machine protection domains.
-
FIG. 2A is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.FIG. 2A also shows aseparation kernel hypervisor 100 executing on native hardware platform resources (where the native platform resources may include a plurality of CPUs, buses and interconnects, main memory, Network Interface Cards (NIC), Hard Disk Drives (HDD), Solid State Drives (SSD), Graphics Adaptors, Audio Devices, Mouse/Keyboard/Pointing Devices, Serial I/O, USB, and/or Raid Controllers, etc.), where the separation kernel hypervisor may support the execution, isolated and/or partitioning in time and space, between a plurality of guest operating system protection domains. Here, some implementations may involve a guest operating system protection domains which may contain a guest operating system, and/or avirtualization assistance layer 400 or 499 (which, themselves, may contain VAL mechanisms, 500, or 597. 598, 599, respectively). Further, theseparation kernel hypervisor 100 may include, access and/or involve various CPU identification instruction virtualization mechanisms, provided for the purpose of varying results returned to a monitored guest responsive to queries or other requests for CPU identification instructions. Here, for example, such mechanism may include reporting a CPU model, stepping, clock speed, or other configuration information that is configurable, rather than reporting a single, unchanging value, or the actual value from the physical CPU. Moreover, while the separation kernel hypervisors shown in the later drawings of the present inventions do not explicitly show this subcomponent, it is hereby noted that such implementations may include, access or otherwise involve such subcomponent or mechanisms, as well. -
FIG. 2A shows both aguest operating system 300, and avirtualization assistance layer 400 executing within the same guest operating system virtualmachine protection domain 200. In some implementations, thevirtualization assistance layer 400 may provide the execution environment for the memory access VAL mechanisms 500 (also 597, 598, 599; hereinafter, together, “VAL mechanisms”). Further, thevirtualization assistance layer 400 may assist the separation kernel hypervisor in virtualizing portions of the platform resources exported to a given guest operating system (e.g., Virtual CPU/ABI, Virtual chipset ABI, set of virtual devices, set of physical devices, and/or firmware, etc., assigned to a givenguest operating system 300 and/or guest virtual machine protection domain 200). Some systems and methods herein utilizing such virtualization assistance layer may include or involve (but are not strictly limited to) a self-assisted virtualization component, e.g., with an illustrative implementation shown inFIG. 2B . - Further, a monitored
guest operating system 300 may include guest operating system virtualization probing code (discussed in more detail in connection withFIG. 8 , below) that may be malicious code installed for purposes of fingerprinting or otherwise probing or determining if the operating system is running under control of a particular hypervisor by examining the hardware environment presented to it. - The
guest operating system 300 and the virtualization assistance layer 400 (which may include VAL mechanism(s) 500) are isolated from each other by theseparation kernel hypervisor 100. In implementations herein, theguest operating system 300 cannot tamper with, bypass, or corrupt thevirtualization assistance layer 400, nor can it tamper with, bypass or corrupt theVAL mechanisms 500. Since theVAL mechanisms 500 are isolated from theguest operating system 300, theVAL mechanisms 500 are able to act on a portion of (or the entirety, depending on policy and configuration) of theguest operating system 300 and its assigned resources in a manner that is (a) is transparent to theguest operating system 300 and (b) not able to be tampered with by theguest operating system 300 or its assigned resources (e.g., errant and/or malicious device DMA originated by devices assigned to the guest operating system 300), and (c) not able to be bypassed by theguest operating system 300. For example, theVAL mechanisms 500, within the givenvirtualization assistance layer 400, may read and/or modify portions of theguest operating system 300 and resources to which theGuest Operating System 300 has been granted access (by the Separation Kernel Hypervisor 100), while none of theGuest Operating System 300 nor the resources to which has access may modify any portion of theVAL mechanisms 500 and/orvirtualization assistance layer 400. - By having a given
virtualization assistance layer 400 and a givenGuest Operating System 300 within the within the same Guest VirtualMachine Protection Domain 200, isolated from each other by theSeparation Kernel Hypervisor 100, various benefits, non-penalties, or mitigation of penalties, such as the following, may be conferred to the system at large and to theVAL mechanisms 500. - Increased Spatial and Temporal Locality of Data
- By being contained within the same Guest Virtual
Machine Protection Domain 300, thevirtualization assistance layer 200, and/or corresponding private (local)VAL mechanisms 500 existing in that same Guest VirtualMachine Protection Domain 300, have greater access, such as in time and space, to the resources of theGuest Operating System 300 than would entities in other guest virtual machine protection domains or other Guest Operating Systems; e.g., the subject guest virtual machine protection domain has faster responsiveness and/or has lower latency than if processed in another guest virtual machine protection domain. Though such resources are still accessed in a manner that is ultimately constrained by theSeparation Kernel Hypervisor 100, there is less indirection and time/latency consumed in accessing the resources: - In one illustrative case, the
VAL mechanisms 500 private (local) to a given Guestvirtualization assistance layer 200 and its associatedGuest Operating System 300 can react faster to physical memory access issues, and not need to wait on actions from another entity in another guest virtualmachine protection domain 200 or guest operating system 300 (which may themselves have high latency, be corrupted, unavailable, poorly scheduled, or subject to a lack of determinism and/or resource constraint, or improper policy configuration, etc.). - Here, for example, if a
Guest Operating System 300 was to monitor aGuest Operating System 399 located within another Guest Virtual Machine Protection Domain 107, it would encounter penalties in time and space for accessing that Guest Operating System and its resources; furthermore, there is increased code, data, scheduling, and/or security policy complexity to establish and maintain such a more complex system; such increases in complexity and resources allow for more bugs in the implementation, configuration, and/or security policy establishment and maintenance. - Scalability and Parallelism
- Each
Guest Operating System 300 may have avirtualization assistance layer 200, andVAL mechanisms 500, that are private (local) to the Guest VirtualMachine Protection Domain 200 that contains both thatGuest Operating System 300, thevirtualization assistance layer 400, and the VAL mechanisms. - Fault Isolation, Low Level of Privilege, Defense in Depth, Locality of Security Policy, and Constraint of Resource Access
- Here, for example, relative to the extremely high level of privilege of the
separation kernel hypervisor 100, thevirtualization assistance layer 400, theVAL mechanism 500, and theGuest Operating System 300 within the same Guest VirtualMachine Protection Domain 200 are only able to act on portions of that Guest Virtual Machine Protection Domain 200 (subject to the Separation Kernel Hypervisor 100) and not portions of other Guest Virtual Machine Protection Domains (nor their contained or assigned resources). - Subject to the isolation guarantees provided by the
Separation Kernel Hypervisor 100, thevirtualization assistance layer 400 accesses only the resources of theGuest Operating System 300 within the same Guest VirtualMachine Protection Domain 200 and thatvirtualization assistance layer 400 is not able to access the resources of other Guest Operating Systems. - As such, if there is corruption (bugs, programmatic errors, malicious code, code and/or data corruption, or other faults, etc.) within a given Guest Virtual
Machine Protection Domain 200 they are isolated to that Guest VirtualMachine Protection Domain 200. They do not affect other Guest VirtualMachine Protection Domains 299 nor do they affect theSeparation Kernel Hypervisor 100. This allows the Separation Kernel Hypervisor to act upon (e.g., instantiate, maintain, monitor, create/destroy, suspend, restart, refresh, backup/restore, patch/fix, import/export etc.) a plurality of Guest VirtualMachine Protection Domains 200 and their correspondingvirtualization assistance layer 400 and VAL mechanisms 500 (or even Guest Operating Systems 300) without corruption of the most privileged execution context of the system, theSeparation Kernel Hypervisor 100. - Similarly, the faults that may occur within a
virtualization assistance layer 400 or the VAL mechanisms 500 (e.g., by corruption of software during delivery) are contained to the Guest VirtualMachine Protection Domain 200 and do not corrupt any other Guest Virtual Machine Protection Domain; nor do they corrupt theSeparation Kernel Hypervisor 100. - Furthermore, the faults within a
Guest Operating System 300 are contained to thatGuest Operating System 300, and do not corrupt either thevirtualization assistance layer 400 or theVAL mechanisms 500. -
FIG. 2B is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.FIG. 2B illustrates a variation ofFIG. 2A where aminimal runtime environment 398 executes in place of a (larger/more complex) guest operating system, within the virtualmachine protection domain 298. Here, a minimal runtime environment may be an environment such as a VDS (virtual device server), and/or a LSA (LynxSecure application), etc. Theminimal runtime environment 398 can be used for policy enforcement related to activities reported by a virtualization assistance layer and/or instruction execution detection/interception mechanisms; such an environment is also monitored by a virtualization assistance layer and/or instruction execution detection/interception mechanisms private to the guest operating system virtual machine protection domain containing the minimal runtime environment. Various virtual resources orsubcomponents 598 belong and are private to theVAL 498 of theguest operating system 398, and are protected from and invisible to the guest. In one specific implementation, suchvirtual resources 598 may include one or more ofvirtual devices 597, VAL internal I/O addresses 598, and/or VALinternal memory regions 599. -
FIG. 3 is a block diagram illustrating an exemplary system and separation kernel Hypervisor architecture consistent with certain aspects related to the innovations herein.FIG. 3 also shows certain detailed aspects with respect toFIG. 2A etc, where the guest operating system may attempt to query devices or resources such as by including a plurality of code and/or data which may constitute execution contexts which may include the following types of software including any/all of which malicious code may attempt to corrupt or utilize: malicious code, anti-virus software, corrupted anti-virus software, integrity checkers, corrupted integrity checkers, rootkits, return oriented rootkits, etc. The invention is not limited to memory access attempts by malicious code and is discussed below via illustrative examples. - For example, in
FIG. 3 , ifantivirus software 2001 executes within a givenguest operating system 300, and suchanti-virus software 2001 is itself corrupted, and itself executesmalicious code 2002 or fails to prevent the execution ofmalicious code 2002, the corruption is constrained to the givenguest operating system 300, and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or viaVAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtualmachine protection domain 200 as theguest operating system 300. - With regard to other exemplary implementations, as may be appreciated in connection with
FIG. 3 , if an integrity checker 2003 (e.g., a “security” component or driver within a guest operating system 300) executes within a givenguest operating system 300, andsuch integrity checker 2003 is itself corrupted into a corrupted integrity checker 2004 (and executes malicious code, or fails to prevent the execution of malicious code), the corruption is constrained to the givenguest operating system 300, and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by various mechanisms within the VAL. - With regard to another illustration, again with reference to
FIG. 3 , if arootkit 2006 executes within the guest operating system 300 (e.g., by having fooled theIntegrity Checker 2003 by the nature of the root kit being a return orientedrootkit 2007, which are designed specifically to defeat integrity checkers) the corruption is constrained to the givenguest operating system 300, and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or viaVAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtualmachine protection domain 200 as theguest operating system 300. - In another example, again with respect to
FIG. 3 , if a polymorphic virus 2005 (an entity designed to defeat integrity checkers, among other things) executes within the guest operating system 300 (e.g., by having fooled theintegrity checker 2003, or by having the a corrupted integrity checker 2003) the corruption is constrained to the givenguest operating system 300, and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or viaVAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtualmachine protection domain 200 as theguest operating system 300. - In general, referring to
FIG. 3 , if amalicious code 2000 executes within the guest operating system 300 (e.g., by means including, but not limited strictly to bugs, defects, bad patches, code and/or data corruption, failed integrity checkers, poor security policy, root kits, viruses, trojans, polymorphic viruses, and/or other attack vectors and/or sources of instability within theguest operating system 300 etc.), the corruption is constrained to the givenguest operating system 300, and the corruption may be acted upon (e.g., detected, notified, prevented, mitigated, reported, tracked, modified/patched, suspended, halted, restarted, eradicated, etc.) by mechanisms such as detection mechanisms (not shown) within the VAL or viaVAL mechanisms 500 that involve virtual hardware presentation features, and is provided within the same guest virtualmachine protection domain 200 as theguest operating system 300. - Furthermore, in the examples above and other cases, such corruption of the
guest operating system 300, and the resources to which it has access, do not corrupt theVAL mechanisms 500 or other mechanisms within the VAL, thevirtualization assistance layer 400, the guest virtualmachine protection domain 200, or plurality of other such resources in the system (e.g., other guest virtual machine protection domains 299), or theseparation kernel hypervisor 100. - In some implementations, the
VAL mechanisms 500, in conjunction with thevirtualization assistance layer 400, and theseparation kernel hypervisor 100, may utilize various methods and mechanisms such as the following, given by way of illustration and example but not limitation, to act with and upon its associatedguest operating system 300 the resources assigned to theguest operating system 300, and the systems behavior generated thereto and/or thereby. -
FIG. 4 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein. For example,FIG. 4 illustrates resources that may be assigned to aGuest Operating System 300 consistent with certain aspects related to the innovations herein. -
FIG. 4 shows an illustrative extension of eitherFIG. 2 , and/orFIG. 3 , where the guest operating system may have a plurality of code and/or data which may constitute execution contexts which may include the following types of software mechanisms and/or constructs user space code and data that may be associated with an unprivileged mode of CPU Malware execution (as used herein ‘user space’ being an execution environment of low privilege, versus an execution environment of high privilege, such as kernel space), which may contain processes, tasks, and/or threads, etc.; kernel space code and data, that may be associated with a privileged mode of CPU execution, which may contain tasks, threads, interrupt handlers, drivers, etc.; shared code and data, that may be associated with either privileged and/or unprivileged modes of CPU execution, and which may include signal handlers, Inter Process Communication Mechanisms (IPC), and/or user/kernel mode APIs. It also may include main memory that may be accessed by the CPU, by DMA from devices, or both. It also shows protection mechanisms including hardware CPU virtualization protection mechanisms, and hardware virtualization DMA protection mechanisms. Further,VAL mechanisms - Such resources, explained here by way of example, not limitation, may include a subset of (a)
hardware platform resources 600, virtualized hardware platform resources (hardware platform resources 600 subject to further constraint by theseparation kernel hypervisor 100, the hardware CPUvirtualization protection mechanisms 602, and/or the hardware virtualization DMA protection mechanisms 601), and execution time on a CPU 700 (or a plurality of CPUs, e.g., 700 to 731) (scheduling time provided by the separation kernel hypervisor 100), and space (memory 900 provided by the separation kernel hypervisor) within which theguest operating system 300 may instantiate and utilize constructs of the particularguest operating system 300, such as a privileged (“kernel” space) modes of execution, non-privileged (“user” space) modes of execution, code and data for each such mode of execution (e.g., processes, tasks, threads, interrupt handlers, drivers, signal handlers, inter process communication mechanisms, shared memory, shared APIs between such entities/contexts/modes, etc. -
FIG. 5 is a block diagram illustrating an exemplary system and separation kernel hypervisor architecture consistent with certain aspects related to the innovations herein.FIG. 5 shows an illustrative implementation as may be associated withFIG. 2 ,FIG. 3 , and/orFIG. 4 , where various VAL mechanisms, which may be within the virtualization assistance layer, may include the various monitoring and presentation mechanisms such as query monitor(s), instruction monitor(s), virtual hardware/device presentation mechanisms, etc.FIG. 5 also illustrates an import/export mechanism that may be used by a virtualization assistance layer and/or VAL mechanisms to communicate between themselves and other virtualization assistance layer and/or VAL mechanisms in other guest operating system virtual machine protection domains (subject to the security policies established, maintained, and enforced by the separation kernel hypervisor), in an isolated, secure, and even monitored fashion. -
FIG. 5 illustrates mechanism and resources that may be used by theVAL mechanisms 500 to monitor aguest operating system 300. Such mechanisms and resources may include a memory monitor 501 and an instruction monitor 502. - The
virtualization assistance layer 400 and/or theVAL mechanisms 500 may also use anexport API 509 and/or an import API 599 (as may be configured and governed by the separation kernel hypervisor 100), in order to provide secure communication between a plurality of virtualization assistance layers (e.g., virtualization assistance layers 400 to 499) and/or a plurality of VAL mechanisms (e.g.,VAL mechanisms 500 to 599). - Innovations set forth below, as also described in additional detail elsewhere herein via notation to the reference numerals in the description below, reside around various combinations, subcombinations and/or interrelated functionality of the following features and/or aspects: (i) a separation kernel hypervisor that ensures the isolation of multiple guest Operating Systems each in its own Virtual Machine (VM); (ii) a virtualization assistance layer of software that runs within the same protection domain as the guest Virtual Machine, but is not directly accessible by the guest; (iii) a virtualization assistance layer as in (ii) that implements a virtual motherboard containing a virtual CPU and virtual devices such as disk controllers, USB controllers, keyboard, mouse, and serial interfaces; (iv) a mechanism within the VAL that returns results similar to physical hardware for configuration queries to the virtual controllers; (v) a mechanism within the VAL to vary the location of non-standard, private I/O devices at guest startup time; (vi) a mechanism within the VAL to vary the location and size of non-standard, private memory areas at guest startup time; and/or (vii) a mechanism within the hypervisor to vary the results of execution of CPU identification instructions in the processor according to configuration data for the hypervisor.
- Systems and mechanisms, and example embodiments, of the
VAL mechanisms 500 may include: - 1. Monitoring of CPU (and CPU cache based) guest OS virtual device access (originated from a plurality of resources available to the guest operating system 300 (e.g., in
FIGS. 3 and 4 , etc), as directed by execution and resources (shown inFIG. 3 ) within theguest OS 300. For virtual devices assigned to theguest OS 300, theseparation kernel hypervisor 100 may trap and perform the processing herein regarding access to such device(s), and then pass associated data regarding that trap to thevirtualization assistance layer 400. Thevirtualization assistance layer 400 may then pass the associated data of that trap to theVAL mechanisms 500. - The monitoring of
guest operating system 300 virtual device access, includes, but is not limited to, constructs inguest operating system 300 devices which may have semantics specific to a specific hardware architecture. For example, a virtualized Network Interface, a virtualized disk controller, or a virtualized interrupt controller, any of which may be probed by guest software intent on determining if it is running under a hypervisor. - The monitoring of
guest operating system 300 device access includes, but is not limited to, constructs inguest operating system 300 devices (including the resources shown inFIGS. 3 and 4 ) which may have semantics specific to the implementation of a particular separation kernel hypervisor. - For all such attempts by the
Guest Operating System 300, the Separation Kernel Hypervisor 100 (when configured to do so) may trap such access attempts, then pass associated data of that trap to thevirtualization assistance layer 400 and/orVAL mechanisms 500. -
FIGS. 6 and 7 are representative sequence/flow diagrams illustrating exemplary systems, methods, and Separation Kernel Hypervisor processing/architecture consistent with certain aspects related to the innovations herein.FIGS. 6 and 7 relate, inter alia, to the guest operating system attempting to perform various fingerprinting operations such as: query or perform other processing in connection with virtual devices, perform processing in connection with non-standard, private I/O devices or memory areas at guest startup time, execute or otherwise process data in connection with the issuance of CPU identification instructions, etc. - Turning to the illustrative implementations/aspects of
FIG. 6 , atstep 805, aGuest Operating System 300 processes a request related to virtualization probing code, such as configuration and/or identification queries pertaining to the virtual hardware environment. Atstep 815, the request is sent to the SeparationKernel Hypervisor SKH 100. TheSKH 100 ensures the isolation of multiple guest Operating Systems each in its own Virtual Machine (VM) (step i). Atstep 820, theSKH 100 transitions execution to theVirtualization Assistance Layer 400. TheSKH 100 processes instructions to execute aVirtualization Assistance Layer 400 that runs within the same protection domain as the Guest Virtual Machine, but which is not directly accessible by the guest (step ii). Further, according to some implementations at guest startup time, theVAL 400 may vary the location of non-standard, private I/O devices (step v) and/or vary the location and size of non-standard, private memory areas (step vi). Then, at 840, theVAL 400 may implement thevirtual devices 500, e.g., a virtual motherboard including at least one virtual device such as a virtual CPU, a disk controller, a USB controller, keyboard, mouse and serial interface(s) (step iii). Next, for configuration queries to thevirtual devices 500 at step (iv), the VAL returns results similar to physical hardware after transitioning execution fromvirtual devices 500 toVAL 400, at 845. Next, atstep 825 the virtualization assistance layer transitions execution back to the Separation Kernel Hypervisor, or the Separation Kernel Hypervisor transitions execution from the virtualization assistance layer back to the Separation Kernel Hypervisor. - For a CPU identification instruction, the
SKH 100 atstep 835 transitions execution to aCPU Instruction Handler 101 that varies the results of execution of the CPU identification instructions in the processor according to configuration data for the hypervisor (step vii). Atstep 830, the results of the CPUidentification instruction handler 101 is returned to theSKH 100. Further, in order to change the virtualized hardware environment presented to an operation system in various ways to prevent “fingerprinting”, execution may cycle a multiple times betweensteps 805 through 845. - As explained above in connection with
FIG. 6 , the virtual machine platform presented to a guest in a hypervisor may be varied, or presented to such operating system in a specified manner, in order to prevent software running in the guest from discovering that it is being run under control of the hypervisor. - Turning to
FIG. 7 , such illustrative system or process begins atstep 905 where a Separation Kernel Hypervisor ensures the isolation of multiple guest Operating Systems each in its own Virtual Machine (VM). Next, a Virtualization Assistance Layer of software is implemented, at 910, which runs within the same protection domain as the guest Virtual Machine, but is not directly accessible by the guest. The virtualization assistance layer then implements, at 915, a virtual motherboard containing a virtual CPU and virtual devices such as disk controllers, USB controllers, keyboard, mouse, and serial interfaces. Here, in some implementations at a guest startup time, the VAL may vary the location of non-standard, private I/O devices, at 935, and/or the VAL may vary the location and/or size of non-standard, private memory areas, at 940. - Processing then proceeds to a virtual
hardware presentation phase 960, wherein one or more of a variety of virtual hardware presentation mechanisms and/or VAL mechanisms may optionally be included and/or utilized responsive to queries, instructions or other processing attempts from a monitored guest. For example, at step 920, a configuration query may be received regarding virtual device(s). Here, the VAL may then return results similar to physical hardware, at 925. Moreover, according to some implementations, upon receiving and executing CPU identification instructions in the processor, at 945, the hypervisor may vary the results of execution of CPU identification instructions in the processor according to configuration data for the hypervisor, at 950. Additional operations from the VAL may also be performed. After such operations and/or processing is performed, execution may then be transitioned back to the VAL, at 970. - The innovations and mechanisms herein may also provide or enable means by which software that attempts to detect that it is running under a hypervisor in order to prevent its detection by malware protection software, or otherwise change its behavior will instead run as it would without the hypervisor.
- Implementations and Other Nuances
- The innovations herein may be implemented via one or more components, systems, servers, appliances, other subcomponents, or distributed between such elements. When implemented as a system, such system may comprise, inter alia, components such as software modules, general-purpose CPU, RAM, etc. found in general-purpose computers, and/or FPGAs and/or ASICs found in more specialized computing devices. In implementations where the innovations reside on a server, such a server may comprise components such as CPU, RAM, etc. found in general-purpose computers.
- Additionally, the innovations herein may be achieved via implementations with disparate or entirely different software, hardware and/or firmware components, beyond that set forth above. With regard to such other components (e.g., software, processing components, etc.) and/or computer-readable media associated with or embodying the present inventions, for example, aspects of the innovations herein may be implemented consistent with numerous general purpose or special purpose computing systems or configurations. Various exemplary computing systems, environments, and/or configurations that may be suitable for use with the innovations herein may include, but are not limited to: software or other components within or embodied on personal computers, appliances, servers or server computing devices such as routing/connectivity components, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, consumer electronic devices, network PCs, other existing computer platforms, distributed computing environments that include one or more of the above systems or devices, etc.
- In some instances, aspects of the innovations herein may be achieved via logic and/or logic instructions including program modules, executed in association with such components or circuitry, for example. In general, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein. The inventions may also be practiced in the context of distributed circuit settings where circuitry is connected via communication buses, circuitry or links. In distributed settings, control/instructions may occur from both local and remote computer storage media including memory storage devices.
- Innovative software, circuitry and components herein may also include and/or utilize one or more type of computer readable media. Computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and/or computing components. By way of example, and not limitation, computer readable media may comprise computer storage media and other non-transitory media.
- Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and can accessed by computing component. Other non-transitory media may comprise computer readable instructions, data structures, program modules or other data embodying the functionality herein, in various non-transitory formats. Combinations of the any of the above are also included within the scope of computer readable media.
- In the present description, the terms component, module, device, etc. may refer to any type of logical or functional circuits, blocks and/or processes that may be implemented in a variety of ways. For example, the functions of various circuits and/or blocks can be combined with one another into any other number of modules. Each module may even be implemented as a software program stored on a tangible memory (e.g., random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be read by a central processing unit to implement the functions of the innovations herein. Or, the modules can comprise programming instructions transmitted to a general purpose computer, to processing/graphics hardware, and the like. Also, the modules can be implemented as hardware logic circuitry implementing the functions encompassed by the innovations herein. Finally, the modules can be implemented using special purpose instructions (SIMD instructions), field programmable logic arrays or any mix thereof which provides the desired level performance and cost.
- As disclosed herein, features consistent with the present inventions may be implemented via computer-hardware, software and/or firmware. For example, the systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them. Further, while some of the disclosed implementations describe specific hardware components, systems and methods consistent with the innovations herein may be implemented with any combination of hardware, software and/or firmware. Moreover, the above-noted features and other aspects and principles of the innovations herein may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various routines, processes and/or operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general-purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.
- Aspects of the method and system described herein, such as the logic, may also be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (“PLDs”), such as field programmable gate arrays (“FPGAs”), programmable array logic (“PAL”) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (“MOSFET”) technologies like complementary metal-oxide semiconductor (“CMOS”), bipolar technologies like emitter-coupled logic (“ECL”), polymer technologies (e.g., Silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, and so on.
- It should also be noted that the various logic and/or functions disclosed herein may be enabled using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media), though do not include transitory media such as carrier waves.
- Unless the context clearly requires otherwise, throughout the description, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
- Although certain presently preferred implementations of the inventions have been specifically described herein, it will be apparent to those skilled in the art to which the inventions pertain that variations and modifications of the various implementations shown and described herein may be made without departing from the spirit and scope of the inventions. Accordingly, it is intended that the inventions be limited only to the extent required by the applicable rules of law.
Claims (28)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/088,460 US11782745B2 (en) | 2014-07-01 | 2020-11-03 | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting and/or other features |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201462019818P | 2014-07-01 | 2014-07-01 | |
PCT/US2015/038918 WO2016004263A1 (en) | 2014-07-01 | 2015-07-01 | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting, and/or other features |
US15/396,231 US10824715B2 (en) | 2014-07-01 | 2016-12-30 | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting, and/or other features |
US17/088,460 US11782745B2 (en) | 2014-07-01 | 2020-11-03 | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting and/or other features |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/396,231 Continuation US10824715B2 (en) | 2014-05-15 | 2016-12-30 | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting, and/or other features |
Publications (3)
Publication Number | Publication Date |
---|---|
US20220137996A1 US20220137996A1 (en) | 2022-05-05 |
US20220261264A9 true US20220261264A9 (en) | 2022-08-18 |
US11782745B2 US11782745B2 (en) | 2023-10-10 |
Family
ID=82800417
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/088,460 Active 2035-12-27 US11782745B2 (en) | 2014-07-01 | 2020-11-03 | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting and/or other features |
Country Status (1)
Country | Link |
---|---|
US (1) | US11782745B2 (en) |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090288167A1 (en) * | 2008-05-19 | 2009-11-19 | Authentium, Inc. | Secure virtualization system software |
US8307169B2 (en) * | 2011-03-10 | 2012-11-06 | Safenet, Inc. | Protecting guest virtual machine memory |
US8473627B2 (en) * | 2008-05-02 | 2013-06-25 | Skytap | Multitenant hosted virtual machine infrastructure |
US9129106B2 (en) * | 2009-11-04 | 2015-09-08 | Georgia Tech Research Corporation | Systems and methods for secure in-VM monitoring |
US9213566B2 (en) * | 2008-11-26 | 2015-12-15 | Red Hat, Inc. | Implementing security in process-based virtualization |
US9361089B2 (en) * | 2008-07-22 | 2016-06-07 | International Business Machines Corporation | Secure patch updates of a virtual machine image in a virtualization data processing system |
US9703444B2 (en) * | 2011-03-31 | 2017-07-11 | Microsoft Technology Licensing, Llc | Dynamic distribution of client windows on multiple monitors |
Family Cites Families (96)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5555385A (en) | 1993-10-27 | 1996-09-10 | International Business Machines Corporation | Allocation of address spaces within virtual machine compute system |
US6075938A (en) | 1997-06-10 | 2000-06-13 | The Board Of Trustees Of The Leland Stanford Junior University | Virtual machine monitors for scalable multiprocessors |
US6049316A (en) | 1997-06-12 | 2000-04-11 | Neomagic Corp. | PC with multiple video-display refresh-rate configurations using active and default registers |
US7035963B2 (en) | 2000-12-27 | 2006-04-25 | Intel Corporation | Method for resolving address space conflicts between a virtual machine monitor and a guest operating system |
JP2004521546A (en) | 2001-03-09 | 2004-07-15 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | Switching method between video signals and image switching device |
US20020166059A1 (en) | 2001-05-01 | 2002-11-07 | Rickey Albert E. | Methods and apparatus for protecting against viruses on partitionable media |
IL160757A0 (en) | 2001-09-14 | 2004-08-31 | Computer Ass Think Inc | Virus detection system |
US7606314B2 (en) | 2002-08-29 | 2009-10-20 | Raritan America, Inc. | Method and apparatus for caching, compressing and transmitting video signals |
US20040221009A1 (en) | 2003-03-04 | 2004-11-04 | Soronti, Inc. | Keyboard-video-mouse (KVM) loop back configuration for virtual presence architecture (VPA) |
US7284278B2 (en) | 2003-03-04 | 2007-10-16 | Dell Products L.P. | Secured KVM switch |
TW583641B (en) | 2003-03-07 | 2004-04-11 | Via Tech Inc | Method for setting pixel clock of a display driving circuit |
US7634419B1 (en) | 2003-06-17 | 2009-12-15 | Cerner Innovation, Inc. | Computerized method and system for restricting access to patient protected health information |
US9020801B2 (en) | 2003-08-11 | 2015-04-28 | Scalemp Inc. | Cluster-based operating system-agnostic virtual computing system |
US7644441B2 (en) | 2003-09-26 | 2010-01-05 | Cigital, Inc. | Methods for identifying malicious software |
US20070061441A1 (en) | 2003-10-08 | 2007-03-15 | Landis John A | Para-virtualized computer system with I/0 server partitions that map physical host hardware for access by guest partitions |
US7644407B2 (en) | 2004-03-05 | 2010-01-05 | Intel Corporation | Method, apparatus and system for seamlessly sharing a graphics device amongst virtual machines |
US20050216759A1 (en) | 2004-03-29 | 2005-09-29 | Rothman Michael A | Virus scanning of input/output traffic of a computer system |
US9606821B2 (en) | 2004-12-17 | 2017-03-28 | Intel Corporation | Virtual environment manager for creating and managing virtual machine environments |
US7647589B1 (en) | 2005-02-07 | 2010-01-12 | Parallels Software International, Inc. | Methods and systems for safe execution of guest code in virtual machine context |
US20060184937A1 (en) | 2005-02-11 | 2006-08-17 | Timothy Abels | System and method for centralized software management in virtual machines |
US8619971B2 (en) | 2005-04-01 | 2013-12-31 | Microsoft Corporation | Local secure service partitions for operating system security |
US7992144B1 (en) | 2005-04-04 | 2011-08-02 | Oracle America, Inc. | Method and apparatus for separating and isolating control of processing entities in a network interface |
US8453148B1 (en) | 2005-04-06 | 2013-05-28 | Teradici Corporation | Method and system for image sequence transfer scheduling and restricting the image sequence generation |
US8200796B1 (en) | 2005-05-05 | 2012-06-12 | Digital Display Innovations, Llc | Graphics display system for multiple remote terminals |
GB0517615D0 (en) | 2005-08-30 | 2005-10-05 | Ecebs Ltd | Improved smartcard system |
US8327353B2 (en) | 2005-08-30 | 2012-12-04 | Microsoft Corporation | Hierarchical virtualization with a multi-level virtualization mechanism |
US7499057B2 (en) | 2005-09-09 | 2009-03-03 | Microsoft Corporation | Address translation in an integrated graphics environment |
US7475183B2 (en) | 2005-12-12 | 2009-01-06 | Microsoft Corporation | Large page optimizations in a virtual machine environment |
US8296759B1 (en) | 2006-03-31 | 2012-10-23 | Vmware, Inc. | Offloading operations to a replicate virtual machine |
US8056076B1 (en) | 2006-03-31 | 2011-11-08 | Vmware, Inc. | Method and system for acquiring a quiesceing set of information associated with a virtual machine |
US7845009B2 (en) | 2006-05-16 | 2010-11-30 | Intel Corporation | Method and apparatus to detect kernel mode rootkit events through virtualization traps |
US20140373144A9 (en) | 2006-05-22 | 2014-12-18 | Alen Capalik | System and method for analyzing unauthorized intrusion into a computer network |
US7870411B2 (en) | 2006-07-17 | 2011-01-11 | Xensource, Inc. | Tracking current time on multiprocessor hosts and virtual machines |
US8201244B2 (en) | 2006-09-19 | 2012-06-12 | Microsoft Corporation | Automated malware signature generation |
US8595487B2 (en) | 2006-11-01 | 2013-11-26 | Vmware, Inc. | Virtualization hardware for device driver isolation |
WO2008077628A2 (en) | 2006-12-22 | 2008-07-03 | Virtuallogix Sa | System for enabling multiple execution environments to share a device |
US8380987B2 (en) | 2007-01-25 | 2013-02-19 | Microsoft Corporation | Protection agents and privilege modes |
CN101241445B (en) | 2007-02-08 | 2011-07-27 | 联想(北京)有限公司 | Virtual machine system and its method for accessing display card |
US8375115B2 (en) | 2007-02-16 | 2013-02-12 | Emulex Corporation | Methods, apparatus, and systems for integrated management, graphics and I/O control of server systems |
US20080320594A1 (en) | 2007-03-19 | 2008-12-25 | Xuxian Jiang | Malware Detector |
US8363244B2 (en) | 2007-03-27 | 2013-01-29 | Xerox Corporation | Updating authentication server lists for users accessing shared access devices |
US20080244212A1 (en) | 2007-03-29 | 2008-10-02 | Rothman Michael A | System and method to enable hierarchical data spilling |
US9246938B2 (en) | 2007-04-23 | 2016-01-26 | Mcafee, Inc. | System and method for detecting malicious mobile program code |
US8875266B2 (en) | 2007-05-16 | 2014-10-28 | Vmware, Inc. | System and methods for enforcing software license compliance with virtual machines |
US7853744B2 (en) | 2007-05-23 | 2010-12-14 | Vmware, Inc. | Handling interrupts when virtual machines have direct access to a hardware device |
US8141163B2 (en) | 2007-07-31 | 2012-03-20 | Vmware, Inc. | Malicious code detection |
US8763115B2 (en) | 2007-08-08 | 2014-06-24 | Vmware, Inc. | Impeding progress of malicious guest software |
US20090055157A1 (en) | 2007-08-23 | 2009-02-26 | Beyond Blades Ltd. | Server Having Remotely Manageable Emulated Functions |
US20090204964A1 (en) | 2007-10-12 | 2009-08-13 | Foley Peter F | Distributed trusted virtualization platform |
US7941382B2 (en) | 2007-10-12 | 2011-05-10 | Microsoft Corporation | Method of classifying and active learning that ranks entries based on multiple scores, presents entries to human analysts, and detects and/or prevents malicious behavior |
US7797748B2 (en) | 2007-12-12 | 2010-09-14 | Vmware, Inc. | On-access anti-virus mechanism for virtual machine architecture |
CA2661398C (en) | 2008-04-05 | 2016-05-17 | Third Brigade Inc. | System and method for intelligent coordination of host and guest intrusion prevention in virtualized environment |
EP2316071A4 (en) | 2008-06-19 | 2011-08-17 | Servicemesh Inc | Cloud computing gateway, cloud computing hypervisor, and methods for implementing same |
US9069599B2 (en) | 2008-06-19 | 2015-06-30 | Servicemesh, Inc. | System and method for a cloud computing abstraction layer with security zone facilities |
US9459928B2 (en) | 2008-08-22 | 2016-10-04 | Hewlett Packard Enterprise Development Lp | Remote graphics console and virtual media access to virtual machine guests |
JP2010049627A (en) | 2008-08-25 | 2010-03-04 | Hitachi Software Eng Co Ltd | Computer virus detection system |
US8073990B1 (en) | 2008-09-23 | 2011-12-06 | Teradici Corporation | System and method for transferring updates from virtual frame buffers |
US20100146267A1 (en) | 2008-12-10 | 2010-06-10 | David Konetski | Systems and methods for providing secure platform services |
US8341749B2 (en) | 2009-06-26 | 2012-12-25 | Vmware, Inc. | Preventing malware attacks in virtualized mobile devices |
US8352941B1 (en) | 2009-06-29 | 2013-01-08 | Emc Corporation | Scalable and secure high-level storage access for cloud computing platforms |
US8490086B1 (en) | 2009-06-30 | 2013-07-16 | Symantec Corporation | Filtering I/O communication of guest OS by inserting filter layer between hypervisor and VM and between hypervisor and devices |
US8341627B2 (en) | 2009-08-21 | 2012-12-25 | Mcafee, Inc. | Method and system for providing user space address protection from writable memory area in a virtual environment |
US8490189B2 (en) | 2009-09-25 | 2013-07-16 | Intel Corporation | Using chipset-based protected firmware for host software tamper detection and protection |
KR101620058B1 (en) | 2009-11-23 | 2016-05-24 | 삼성전자주식회사 | Apparatus for switching screen between virtual machines and method thereof |
CN102763098B (en) | 2009-12-14 | 2016-02-17 | 思杰系统有限公司 | For the method and system communicated between credible and insincere virtual machine |
KR101081907B1 (en) | 2010-01-05 | 2011-11-09 | 성균관대학교산학협력단 | Apparatus for virtualization |
US8301746B2 (en) | 2010-01-26 | 2012-10-30 | International Business Machines Corporation | Method and system for abstracting non-functional requirements based deployment of virtual machines |
US20110225458A1 (en) | 2010-03-09 | 2011-09-15 | Microsoft Corporation | Generating a debuggable dump file for an operating system kernel and hypervisor |
US9501644B2 (en) | 2010-03-15 | 2016-11-22 | F-Secure Oyj | Malware protection |
US8549643B1 (en) | 2010-04-02 | 2013-10-01 | Symantec Corporation | Using decoys by a data loss prevention system to protect against unscripted activity |
US8839239B2 (en) | 2010-06-15 | 2014-09-16 | Microsoft Corporation | Protection of virtual machines executing on a host device |
US20120011077A1 (en) | 2010-07-12 | 2012-01-12 | Bhagat Bhavesh C | Cloud Computing Governance, Cyber Security, Risk, and Compliance Business Rules System and Method |
US8135468B2 (en) | 2010-08-09 | 2012-03-13 | Pacesetter, Inc. | Systems and methods for estimating left atrial pressure (LAP) in patients with acute mitral valve regurgitation for use by an implantable medical device |
WO2012027669A1 (en) | 2010-08-26 | 2012-03-01 | Verisign, Inc. | Method and system for automatic detection and analysis of malware |
US8539584B2 (en) | 2010-08-30 | 2013-09-17 | International Business Machines Corporation | Rootkit monitoring agent built into an operating system kernel |
WO2012035575A1 (en) | 2010-09-14 | 2012-03-22 | Hitachi, Ltd. | Method and device for eliminating patch duplication |
US8849941B2 (en) | 2010-09-30 | 2014-09-30 | Microsoft Corporation | Virtual desktop configuration and operation techniques |
EP2466466B1 (en) | 2010-12-09 | 2013-10-16 | Siemens Aktiengesellschaft | Method for detecting errors when executing a real-time operating system |
US9317690B2 (en) | 2011-03-28 | 2016-04-19 | Mcafee, Inc. | System and method for firmware based anti-malware security |
US9721089B2 (en) | 2011-05-06 | 2017-08-01 | The University Of North Carolina At Chapel Hill | Methods, systems, and computer readable media for efficient computer forensic analysis and data access control |
US8584211B1 (en) | 2011-05-18 | 2013-11-12 | Bluespace Software Corporation | Server-based architecture for securely providing multi-domain applications |
US9129123B2 (en) | 2011-06-13 | 2015-09-08 | Lynx Software Technologies, Inc. | Systems and methods of secure domain isolation involving separation kernel features |
US9069586B2 (en) | 2011-10-13 | 2015-06-30 | Mcafee, Inc. | System and method for kernel rootkit protection in a hypervisor environment |
US8977848B1 (en) | 2011-11-15 | 2015-03-10 | Rockwell Collins, Inc. | Method and system for reconciling safety-critical and high assurance security functional requirements between safety and security domains |
US9152548B2 (en) | 2012-01-17 | 2015-10-06 | Vmware, Inc. | Controlling access to a privileged resource in user-mode system level mobile virtualization using a ptrace () system call |
US20130312099A1 (en) | 2012-05-21 | 2013-11-21 | Mcafee, Inc. | Realtime Kernel Object Table and Type Protection |
EP4036721A1 (en) | 2012-06-26 | 2022-08-03 | Lynx Software Technologies Inc. | Systems and methods involving features of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, rootkit detection prevention and further features |
WO2014100273A1 (en) | 2012-12-18 | 2014-06-26 | Dynavisor, Inc. | Dynamic device virtualization |
US9792459B2 (en) | 2013-04-29 | 2017-10-17 | Sri International | Flexible policy arbitration control suite |
US20150261952A1 (en) | 2014-03-13 | 2015-09-17 | Unisys Corporation | Service partition virtualization system and method having a secure platform |
US9672058B2 (en) | 2014-03-13 | 2017-06-06 | Unisys Corporation | Reduced service partition virtualization system and method |
US9483639B2 (en) | 2014-03-13 | 2016-11-01 | Unisys Corporation | Service partition virtualization system and method having a secure application |
US9203855B1 (en) | 2014-05-15 | 2015-12-01 | Lynx Software Technologies, Inc. | Systems and methods involving aspects of hardware virtualization such as hypervisor, detection and interception of code or instruction execution including API calls, and/or other features |
US9390267B2 (en) | 2014-05-15 | 2016-07-12 | Lynx Software Technologies, Inc. | Systems and methods involving features of hardware virtualization, hypervisor, pages of interest, and/or other features |
WO2016004263A1 (en) | 2014-07-01 | 2016-01-07 | Lynx Software Technologies, Inc. | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting, and/or other features |
US9213840B2 (en) | 2014-05-15 | 2015-12-15 | Lynx Software Technologies, Inc. | Systems and methods involving features of hardware virtualization, hypervisor, APIs of interest, and/or other features |
-
2020
- 2020-11-03 US US17/088,460 patent/US11782745B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8473627B2 (en) * | 2008-05-02 | 2013-06-25 | Skytap | Multitenant hosted virtual machine infrastructure |
US20090288167A1 (en) * | 2008-05-19 | 2009-11-19 | Authentium, Inc. | Secure virtualization system software |
US9361089B2 (en) * | 2008-07-22 | 2016-06-07 | International Business Machines Corporation | Secure patch updates of a virtual machine image in a virtualization data processing system |
US9213566B2 (en) * | 2008-11-26 | 2015-12-15 | Red Hat, Inc. | Implementing security in process-based virtualization |
US9129106B2 (en) * | 2009-11-04 | 2015-09-08 | Georgia Tech Research Corporation | Systems and methods for secure in-VM monitoring |
US8307169B2 (en) * | 2011-03-10 | 2012-11-06 | Safenet, Inc. | Protecting guest virtual machine memory |
US9703444B2 (en) * | 2011-03-31 | 2017-07-11 | Microsoft Technology Licensing, Llc | Dynamic distribution of client windows on multiple monitors |
Also Published As
Publication number | Publication date |
---|---|
US20220137996A1 (en) | 2022-05-05 |
US11782745B2 (en) | 2023-10-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11782766B2 (en) | Systems and methods involving features of hardware virtualization, hypervisor, APIs of interest, and/or other features | |
US10824715B2 (en) | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting, and/or other features | |
US11861005B2 (en) | Systems and methods involving features of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, rootkit detection/prevention, and/or other features | |
US10051008B2 (en) | Systems and methods involving aspects of hardware virtualization such as hypervisor, detection and interception of code or instruction execution including API calls, and/or other features | |
US10095538B2 (en) | Systems and methods involving features of hardware virtualization, hypervisor, pages of interest, and/or other features | |
US8763115B2 (en) | Impeding progress of malicious guest software | |
EP2766843B1 (en) | System and method for kernel rootkit protection in a hypervisor environment | |
Ning et al. | Position paper: Challenges towards securing hardware-assisted execution environments | |
KR20190096959A (en) | Event filtering for virtual machine security applications | |
US11782745B2 (en) | Systems and methods involving aspects of hardware virtualization such as separation kernel hypervisors, hypervisors, hypervisor guest context, hypervisor context, anti-fingerprinting and/or other features | |
Vibhute | EPA-RIMM-V: Efficient Rootkit Detection for Virtualized Environments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
FEPP | Fee payment procedure |
Free format text: PETITION RELATED TO MAINTENANCE FEES GRANTED (ORIGINAL EVENT CODE: PTGR); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: PENNANTPARK LOAN AGENCY SERVICING, LLC, AS ADMINISTRATIVE AGENT, FLORIDA Free format text: SECURITY INTEREST;ASSIGNOR:LYNX SOFTWARE TECHNOLOGIES INC.;REEL/FRAME:065881/0393 Effective date: 20231215 |