Obfuscating information in virtualized environments
By intercepting and scrambling hardware requests in virtualized computer systems, the risk of access to sensitive data by hypervisors is solved, ensuring the security and performance of the virtual machine, and avoiding performance problems caused by inaccurate counter values.
Patent Information
- Application Number
- CN202080064365.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-09-24
- Filing Date
- 2020-09-22
- Publication Date
- 2024-12-24
- Estimated Expiration
- 2040-09-22
AI Technical Summary
In a cloud environment, the hypervisor has permission to access any partition on the data of the multi-tenant server, resulting in security risks because it can access sensitive data from cloud users.
By detecting the application's hardware requests, determining whether counter values are included, and intercepting these requests before the hypervisor processes, saving the counter values in secure memory, generating scrambled counter values, updating hardware requests, and providing them to the hypervisor to ensure that the hypervisor cannot access sensitive information.
It effectively prevents the hypervisor from accessing the counter value, maintains the security and performance of the virtual machine, and avoids performance degradation and resource waste caused by inaccurate counter value.
Smart Images

Figure CN114402328B_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to hypervisor operations, and more particularly, to obfuscating time-based information from a hypervisor in a multi-tenant server. Background Art
[0002] Applications and operating systems can operate on a computer system. A computer system can be a memory, a processor, and an input / output interface (I / O). A computer system can be a virtual computer system operated by a hypervisor. Some clients may prefer the flexibility of a virtual computer system. When operating on a virtual computer system, these clients may also prefer security over information. In a cloud environment, an OS instance provided by a cloud user runs on a hypervisor maintained by a cloud provider as an independent partition on the same machine. Typically, the hypervisor has access to data from any partition. This creates a security risk because the cloud provider can essentially access any information from the OS (and the applications running within the OS), including sensitive data of the cloud user.
[0003] Therefore, there is a need in the art to solve the above problems. Summary of the invention
[0004] From a first aspect, the present invention provides a method for hypervisor operation, the method comprising: detecting a hardware request of an application, wherein the application is executed on a virtualized computer system; determining that the hardware request includes a counter, wherein the counter will be updated by the virtualized computer system, and wherein the counter includes a counter value; based on the determination that the hardware request includes the counter, intercepting the hardware request before the hardware request is processed by the hypervisor hosting the virtualized computer system; storing the counter value in a secure memory, the secure memory being obfuscated to the hypervisor; generating an encrypted counter value; updating the hardware request with the encrypted counter value; and after updating the hardware request, providing the hardware request to the hypervisor.
[0005] From another aspect, the present invention provides a system comprising: a memory containing one or more instructions; and a processor communicatively coupled to the memory, the processor being configured in response to reading the one or more instructions to: detect a hardware request of an application, wherein the application is executed on a virtualized computer system; determine that the hardware request includes a counter, wherein the counter is executed by the virtualized computer system, and wherein the counter includes a counter value; based on the determination that the hardware request includes the counter, intercept the hardware request before the hardware request is processed by a hypervisor hosting the virtualized computer system; store the counter value in a secure memory, the secure memory being obfuscated to the hypervisor; generate an encrypted counter value; update the hardware request using the encrypted counter value; and after updating the hardware request, provide the hardware request to the hypervisor.
[0006] Viewed from another aspect, the present invention provides a computer program product for managing program operations, the computer program product comprising a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method for performing the steps of the present invention.
[0007] Viewed from another aspect, the invention provides a computer program stored on a computer readable medium and loadable into the internal memory of a digital computer, the computer program comprising software code portions for performing the steps of the invention when said program is run on a computer.
[0008] From a first aspect, the present invention provides a computer program product, which includes a computer-readable storage medium, the computer-readable storage medium having program instructions embodied therein, the program instructions being configured to: detect a hardware request of an application, wherein the application is executed on a virtualized computer system; determine that the hardware request includes a counter, wherein the counter is executed by the virtualized computer system, and wherein the counter includes a counter value; based on the determination that the hardware request includes the counter, intercept the hardware request before the hardware request is processed by a hypervisor hosting the virtualized computer system; save the counter value in a secure memory, the secure memory being obfuscated to the hypervisor; generate an encrypted counter value; update the hardware request using the encrypted counter value; and after updating the hardware request, provide the hardware request to the hypervisor.
[0009] According to some embodiments, a system, method, and computer program product are disclosed. A hardware request of an application is detected. The application is executed on a virtualized computer system. A determination is made that the hardware request includes a counter. The counter is to be executed by the virtualized computer system. The counter includes a counter value. The hardware request is intercepted before being processed by a hypervisor hosting the virtualized computer system. The interception is based on a determination that the hardware request includes the counter. The counter value is stored in a secure memory. The secure memory is obfuscated to the hypervisor. A scrambled counter value is generated. The hardware request is updated with the scrambled counter value. After the hardware request is updated, it is provided to the hypervisor.
[0010] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The accompanying drawings included in this application are incorporated into the specification and form a part of the specification. They show embodiments of the present disclosure and are used to explain the principles of the present disclosure together with the detailed description. The accompanying drawings only illustrate certain embodiments and do not limit the present disclosure.
[0012] Figure 1 An example computing environment utilizing secure client machines and time-based accuracy consistent with some embodiments of the present disclosure is depicted.
[0013] Figure 2 Example methods for performing obfuscation of timing register and counter values consistent with some embodiments of the present disclosure are depicted.
[0014] Figure 3 Depicted are representative major components of an example computer system that may be used in accordance with some embodiments of the present disclosure.
[0015] Figure 4 A cloud computing environment according to some embodiments of the invention is depicted.
[0016] Figure 5 Abstract model layers according to some embodiments of the invention are depicted.
[0017] Although the present invention is subject to different modifications and alternative forms, its details have been illustrated by way of example in the accompanying drawings and will be described in detail. However, it should be understood that the present invention is not limited to the specific embodiments described. On the contrary, the present invention is intended to cover all modifications, equivalents and alternatives that fall within the scope of the present invention. DETAILED DESCRIPTION
[0018] Aspects of the present disclosure relate to hypervisor operations; more particularly, aspects relate to obfuscating time-based information from a hypervisor in a multi-tenant server. Although the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be understood through a discussion of different examples using this context.
[0019] In an application and operating system (OS) hosting environment, an OS instance provided by a provider can run on a hypervisor maintained by the provider. For example, in a cloud environment, an OS instance can run as a client on a hypervisor maintained by a cloud provider, where the OS instance runs as a separate partition on the same physical system. In some cases, the hypervisor has access to data from any partition. Hypervisor access to any partition can create security risks because the provider can access any information from the OS (and applications running inside the OS), including the user's sensitive data. This issue can be complex because cloud providers can guarantee data privacy or regulations can dictate the protection of sensitive data.
[0020] One class of solutions involves introducing a privilege level above the hypervisor (e.g., a privilege level above the hypervisor is a privilege level that is considered to be trusted) that can intercept any exceptions from partitions that are considered safe to go to the hypervisor. For example, an ultravisor can have an elevated privilege level compared to the hypervisor.
[0021] An elevated privilege handler for exceptions (e.g., a level above the hypervisor) can obfuscate the values of hardware registers accessible to the hypervisor. For example, the values in different hardware registers store information from a user program or OS ("application"). These values and hardware registers corresponding to applications operating on a virtual machine provided by the hypervisor can be inspected and viewed by the hypervisor. Providing an elevated privilege level above the hypervisor can allow different values and hardware registers corresponding to encrypted applications to be viewed from the hypervisor's point of view.
[0022] In another example, a save operation or restore operation ("memory operation") on a portion of memory (e.g., virtual memory provided to an application by a hypervisor) and the hypervisor may be able to access the same portion of virtual memory. By not allowing the hypervisor to access a portion of memory, certain memory operations may be prevented. The portion of virtual memory that is not accessible to the hypervisor may be secure memory. In these examples, the hypervisor may be provided with only the exact amount of information needed to perform different operations, and access to secure memory may not be provided.
[0023] The problem of having increased privilege levels, such as those used by a hypervisor. Many modern computer architectures operate on a technology known as multiprocessing. Multiprocessing can allow a user program or OS to process multiple processes or threads simultaneously. Multiprocessing can allow these applications to execute with increased efficiency or with higher processing throughput. Multiprocessing can rely on very specific hardware requests. For example, an application can send hardware requests to different registers of a processor to perform multithreaded operations. These different registers can be special registers, such as counters, decrementers, or incrementers.
[0024] A counter (a register that counts down using the processor clock and generates a timer interrupt when it crosses zero) can be a fundamental register for a user program or OS, as it is the source of a timer interrupt. A counter can be a fundamental hardware mechanism for preemptive process scheduling deployed in many modern operating systems. In some cases (e.g., for legacy reasons), the counter can be accessible to the hypervisor. With the introduction of hypervisors, the counter can also be obfuscated from the hypervisor; obfuscating the counter can be beneficial in trying and preventing the hypervisor from being exploited in other ways to perform timing attacks by the hypervisor.
[0025] If different special registers (such as counters) are fuzzy and not affected by the hypervisor, the unexpected result is that the application running in the virtual machine may run with worse performance. For example, some counters and other special registers are used to accurately share processing resources and perform context switching between different components. The scheduler, context switcher, stack pointer, program counter or other related processing hardware registers can rely on accurate counter values from the processor (and the hypervisor in the case of the virtual machine). During the operation of some hypervisors and other privileged operations, fuzzy counters are provided to the hypervisor and fuzzy counters are received from the hypervisor. The hypervisor records the original value, stores the value in a secure area of memory that is inaccessible to the hypervisor, and restores the value before returning to the client virtual machine or process. This method may be sufficient for registers that do not decrease or increase with the processor clock or are not a function of the processor clock (that is, registers that are not intended to measure time in any way), but for registers that are indeed related to the processor clock, this method causes incorrect values restored from the secure memory.
[0026] When client virtual machine or application program operates based on fuzzy value, can give process and thread more or less computer resources than they need to perform operation.For example, the inaccurate time slice of multiple parallel executions of program code (for example, thread, process) can prevent some program code from being completed in time.If a certain part of program code is not completed before being interrupted, then it may be requested again, become stagnant or even collapse.Utilize inaccurate counter, can complete a part of program code when there is no interruption corresponding to program completion.The delayed interruption that arrives after the actual completion of program code execution can therefore cause processor idle many cycles.Further, unfinished and reordered program can cause repeated switching between process / thread, to reform the work of completion and interruption, thereby cause wasteful cycle or program to slow down.Further, the action of stopping the execution of the first program code segment and starting the execution of the second program code can have the overhead in the processing, memory or I / O of the computer.
[0027] A counter-aware hypervisor (CAUV) can overcome the problems of other hypervisors by providing obfuscated or scrambled counters to the hypervisor while converting and returning counters to applications that provide relevant values for performing multiprocessing. CAUV can provide placeholder values to the hypervisor that obfuscate information from the hypervisor. CAUV can also measure the time spent in the hypervisor and can adjust the value after the operation is performed by the hypervisor but before the value is restored to the OS or any program running on the OS. By obfuscating information before providing it to the hypervisor, CAUV can maintain security for all guest virtual machines that run using a hypervisor or other related elevated privilege systems. By tracking the different system-level counters and dedicated hardware registers involved in the multiprocessing operations of an application, CAUV can enable the OS to maintain the accuracy of the low-level program counters and provide accurate quality of service.
[0028] Figure 1 An example computing environment 100 utilizing a secure client and time-based accuracy consistent with some embodiments of the present disclosure is depicted. The computing environment 100 may include the following: a plurality of computer systems 110-1, 110-2, 110-3, through 110-n (collectively, 110); one or more client computers 120-1, 120-2, through 120-n (collectively, 120); and a virtualization environment 130 for hosting the client computers 120. The computer system 110 may include physical memory, physical processing resources, and physical I / O for facilitating and hosting the virtualization environment 130. Figure 3An example computer system 300 capable of performing hosting consistent with some embodiments of the present disclosure is depicted. Computer system 110 may be located in a data center. In some embodiments, computer system 110 may be geographically separated. For example, computer system 110-1 may be located in a first location, and computer system 110-2 may be geographically different from computer system 110-1.
[0029] Client computer 120 may be in the form of a virtual machine and a secure virtual machine. For example, client computer 120-1 may be a virtual machine that serves hardware resources of computer systems 110-1 and 110-3 from virtualization environment 130. In another example, client computer 120-2 may be a secure virtual machine that serves hardware resources of server from virtualization environment 130. Client computer 120 may make references to hardware in the form of hardware requests (e.g., arithmetic logic units of a processor, memory references to caches, counters, read commands to dynamic random access memory (DRAM), and store commands to tertiary storage).
[0030] Virtualization environment 130 may be configured to host different computer systems, including client computer 120. Virtualization environment 130 may be a combination of hardware, firmware, and software for hosting virtual machines, and may be executed on computer system 110. Virtualization environment 130 may be provided by a service provider, which is operated by an entity separate from client computer 120. For example, virtualization environment 130 may be a cloud-based service provider that provides computer system 110 to different clients. Service providers of virtualization environment 130 may guarantee different levels of privacy and computer performance.
[0031] Virtualization environment 130 may include the following: memory space 140 for storing program data, operating system data, and virtualized hardware registers; secure memory space 150 for storing program data, operating system data, and virtualized hardware registers; a hypervisor 160 for servicing various hardware requests of client computer 120; and a hypervisor for servicing various hardware requests of client computer 120. Virtualization environment 130 may also include other components, such as a trusted platform module (TPM) (not depicted).
[0032] Virtualization environment 130 may instantiate or create client computers 120 in response to requests from parties requesting computer resources from a cloud provider. For example, a client may request computer resources, and in response, hypervisor 160 may allocate client computer 120-1 by reserving resources of the underlying computer system and reserving a portion of memory space 140 for execution of the client computer. Programs 122-1 and 124-1 may operate on client computer 120-1, and all low-level registers and memory corresponding to the operation of client computer 120-1 may be stored in memory space 140. As program 122-1 executes, and as various program counters, context switches, and other related multiprocessing operations are performed, hypervisor 160 may observe data associated with these elements.
[0033] The virtualization environment 130 can also instantiate or create a client computer 120 from the hypervisor with improved security and privacy. The creation of public and private keys can be performed when the firmware of the computer system 110 or the virtualization environment 130 is manufactured - for example, keys generated by the TPM of the virtualization environment 130. In some embodiments, each computer system 110 can generate a separate public and private key. The private key may not be accessible to the provider of the virtualization environment 130 or the hypervisor 160.
[0034] The virtual machine may make a request to be protected and may wrap the encryption key with a public key. In response to the request, the virtualization environment 130 may operate to protect the virtual machine from the hypervisor 160. For example, the client computer 120-2 may be created by the hypervisor 160 in response to a request from a client. At this point, the client computer 120-2 may operate as a virtual machine in the storage space 140 allocated to it by the hypervisor 160. The client may generate a security request for sending and receiving data using the client computer 120-2. The client computer 120-2 may encrypt the security request using the public key of the virtualization environment 130. The hypervisor 170 may receive the security request from the client computer 120-2, and may move the virtual machine to the secure memory space 150 using the public key, thereby making the client computer 120-2 a secure virtual machine. Further execution of the OS and user programs (e.g., user program 122-2) may exist in the secure storage space 150, and the hypervisor 170 may operate to protect any data input to the hypervisor 160 for different hardware requests. For example, hypervisor 170 may intercept and obfuscate various data inputs requested by hardware such that management program 160 cannot read or otherwise discern the information of the data inputs.
[0035] The virtualization environment 130 may also implement CAUV to maintain accurate counter data for the client computer 120 running as a secure virtual machine. CUAV may also protect information from the hypervisor 160. For example, a hardware request 180 may be sent from the secure virtual machine 120-2 to the virtualization environment 130. The hardware request 180 may be directed to the hypervisor 160. The hypervisor 170 may detect the hardware request 180 and may determine that the request includes a counter (e.g., an 8-bit decrementer) having a counter value. The hypervisor 170 may intercept the hardware request 180 before the hardware request 180 is sent to the hypervisor 160. The hypervisor 170 may store the counter value in the secure storage space 150, and the hypervisor may not be able to access the counter value. The hypervisor 170 may generate a scrambled or obfuscated version of the counter value and may provide the scrambled counter value to the hypervisor 160 so that the hypervisor can execute the hardware request using the scrambled counter value. Figure 1 A number of example operations 182 for performing interception of hardware requests to scramble / obfuscate counters consistent with some embodiments of the present disclosure are depicted in FIG.
[0036] Further, a response 190 to the hardware request 180 may be sent by the hypervisor 160. The response 190 may include an updated counter. The updated counter may be based on a scrambled counter value that was obfuscated by the hypervisor 170. The hypervisor 170 may intercept the response 190 and may de-obfuscate the updated counter. The hypervisor 170 may de-obfuscate the updated counter by offsetting the counter value stored in the secure memory space 150 using the difference between the scrambled version of the counter value and the updated counter value of the hypervisor 160. The hypervisor 170 may send the de-obfuscated updated counter in the response 190 to the virtual machine 120-2. Depicted are a number of example operations 192 for performing an interception of a hardware response to de-scramble / de-obfuscate the counter consistent with some embodiments of the present disclosure.
[0037] Figure 2 An example method 200 for performing fuzzification of timing register and counter values according to some embodiments of the present disclosure is depicted. The method 200 may be performed by a computer system. Figure 3 The computer system 300 depicted in may be configured to perform one or more portions of the method 200. The method 200 may be performed by a CAUV consistent with some embodiments of the present disclosure.
[0038] Beginning at 205, the hypervisor may be monitored at 210 for traffic between an application and the hypervisor. In some embodiments, the application may be a user program, such as an engineering simulation program, a word processing program, or a graphics rendering program. In some embodiments, the application may be an OS, such as a client computer hosted by a virtualization system. Monitoring the traffic may include monitoring an application running within a secure virtual machine - for example, an application that has initiated a secure session with a CAUV that protects memory and certain operational information from inspection by the hypervisor. In some embodiments, monitoring of the traffic may include obfuscating, scrambling, or otherwise randomizing (such as by a random number generator) certain data inputs provided to the hypervisor. For example, if a hardware request includes a particular register value, pointer, or other data element that is not required for the hypervisor to perform an operation on the client computer, the hypervisor may hide, zero, randomize, data shift, or otherwise obfuscate the data element.
[0039] If a hardware request is detected at 215: Y, then at 220 it is determined whether there is a counter within the hardware request. If there is no counter (220: N), method 200 ends at 295. If there is a counter (220: Y), the hardware request can be intercepted at 230. Intercepting a hardware request can be a proactive operation. For example, a hypervisor can detect that a hardware request has been placed in a queue for processing by a hypervisor. The hypervisor can intercept a hardware request before the hypervisor sees or examines the request. Interception of a hardware request can be a reactive operation. For example, a hardware request from a secure virtual machine can be encrypted so that only a hypervisor or another secure element of the virtualized environment can read the hardware request, while the hypervisor does not read the hardware request until it is unencrypted.
[0040] At 240, a counter within the intercepted hardware request may be saved. The counter may be a reference, pointer, value, or other data element of a computer system (e.g., a program counter, a decrementer, a special register, a multi-processing register, a multi-threading register). The counter may include a counter value (e.g., a 3-bit value, an 8-bit value). At 250, the counter value in the intercepted request may be obfuscated. The obfuscation of the counter value may include scrambling, randomization (e.g., by a TPM), byte shifting, zeroing, or otherwise inserting data that is unrelated to the counter value. Obfuscating the counter value may include changing the counter value so that when the hypervisor examines it, the hypervisor cannot discern meaningful information. The obfuscated counter value may be stored in a memory (e.g., a memory space shared with the hypervisor, or a secure memory space that is not accessible to the hypervisor).
[0041] At 260, the updated hardware request may be provided to the hypervisor. Providing the updated hardware request may include providing the hypervisor with a hardware request having an obfuscated counter in decrypted form. Providing the updated hardware request may include moving the hardware request having the obfuscated counter to a queue of the hypervisor. For example, the hypervisor may have a storage space in which different requests and working memories of the hypervisor reside. Providing the updated request at 260 may include the hypervisor moving the updated request from a secure memory that is inaccessible to the hypervisor to a memory space. After providing the updated request at 260, method 200 may end at 295. In some embodiments, method 200 may start again at 205, and the hypervisor may continue to be monitored at 210.
[0042] If there is no hardware request (215: N), then a response to the hardware request can be identified at 270. In some embodiments, if there is an identified response (270: Y), the response can be blocked from being sent back to the application intended by the hypervisor (e.g., the application sending the hardware request corresponding to the response). If there is a response to the hypervisor's hardware request (270: Y), then at 280 the counter can be descrambled.
[0043] The descrambling of the counter may include determining an updated counter value from the hypervisor in the response. The descrambling of the counter may include generating an update amount. For example, the hypervisor may compare the updated counter value from the response with a stored fuzzy counter previously provided to the hypervisor. By comparing these values (e.g., subtracting, adding), the updated amount may be calculated. For example, if the fuzzy counter value is "1011", and if the updated counter value is "0010", the updated amount may be "1001". Thus, the updated amount may be the difference between the counter value before and after being operated by the hypervisor. The updated amount may be used to calculate an updated unfuzzy counter value (e.g., a counter value associated with a counter provided by an application of a client computer). For example, if the counter value before being blurred is "1101" and the descrambled counter has an updated amount "1001", the calculated updated defuzzified counter value will be "0100". Calculating the updated defuzzified counter value may include subtracting the counter value before being blurred from the difference between the blurred counter value and the updated counter value from the hypervisor.
[0044] At 290, the updated deobfuscated counter value may be provided to the application that sent the hardware request with the counter. Providing the updated deobfuscated counter value may include inserting the value into the response. Providing the updated contact obfuscated counter value may include encrypting the response before placing the response in an output queue of the client computer of the application. After providing the updated deobfuscated counter value, method 200 ends at 295. In some embodiments, after providing the updated deobfuscated counter value, at 290, method 200 may continue to monitor the hypervisor at 210.
[0045] Figure 3 Depicted are representative major components of an example computer system 300 (alternatively, a computer) that can be used according to some embodiments of the present disclosure. It should be appreciated that the various components can vary in complexity, quantity, type, and / or configuration. The specific examples disclosed are for illustrative purposes only and are not necessarily the only such variations. Computer system 300 may include processor 310, memory 320, input / output interface (here I / O or I / O interface) 330, and main bus 340. Main bus 340 can provide communication paths for other components of computer system 300. In some embodiments, main bus 340 can be connected to other components, such as a dedicated digital signal processor (not depicted).
[0046] The processor 310 of the computer system 300 may be composed of one or more cores 312A, 312B, 312C, 312D (collectively referred to as 312). The processor 310 may also include one or more memory buffers or caches (not depicted) that provide temporary storage of instructions and data for the core 312. The core 312 may execute instructions on inputs provided from the cache or from the memory 320, and output the results to the cache or memory. The core 312 may include one or more circuits configured to perform one or more methods according to embodiments of the present disclosure. In some embodiments, the computer system 300 may include multiple processors 310. In some embodiments, the computer system 300 may be a single processor 310 with a single core 312.
[0047] The memory 320 of the computer system 300 may include a memory controller 322. In some embodiments, the memory 320 may include a random access semiconductor memory, a storage device, or a storage medium (volatile or non-volatile) for storing data and programs. In some embodiments, the memory may be in the form of a module (e.g., a dual in-line memory module). The memory controller 322 may communicate with the processor 310 to facilitate the storage and retrieval of information in the memory 320. The memory controller 322 may communicate with the I / O interface 330 to facilitate the storage and retrieval of input or output in the memory 320.
[0048] The I / O interface 330 may include an I / O bus 350, a terminal interface 352, a storage interface 354, an I / O device interface 356, and a network interface 358. The I / O interface 330 may connect the main bus 340 to the I / O bus 350. The I / O interface 330 may direct instructions and data from the processor 310 and the memory 320 to different interfaces of the I / O bus 350. The I / O interface 330 may also direct instructions and data from different interfaces of the I / O bus 350 to the processor 310 and the memory 320. The various interfaces may include a terminal interface 352, a storage interface 354, an I / O device interface 356, and a network interface 358. In some embodiments, the different interfaces may include a subset of the aforementioned interfaces (e.g., an embedded computer system in an industrial application may not include a terminal interface 352 and a storage interface 354).
[0049] Logic modules throughout computer system 300 - including but not limited to memory 320, processor 310, and I / O interface 330 - can communicate failures and changes to one or more components to a hypervisor or operating system (not depicted). The hypervisor or operating system can allocate different resources available in computer system 300 and keep track of the location of data in memory 320 and processes assigned to different cores 312. In embodiments that combine or rearrange elements, aspects and capabilities of logic modules can be combined or reallocated. These variations will be apparent to those skilled in the art.
[0050] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings described herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.
[0051] Cloud computing is a service delivery model for convenient, on-demand network access to a shared pool of configurable computing resources. Configurable computing resources are resources that can be quickly deployed and released with minimal management cost or interaction with the service provider, such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.
[0052] Features include:
[0053] On-demand self-service: Cloud consumers can unilaterally and automatically deploy computing capabilities such as server time and network storage on demand without human interaction with the service provider.
[0054] Broad network access: Computing power can be accessed over the network through standard mechanisms that facilitate the use of the cloud through different types of thin-client or thick-client platforms (e.g., mobile phones, laptops, personal digital assistants (PDAs)).
[0055] Resource pool: The computing resources of the provider are grouped into resource pools and serve multiple consumers through a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated on demand. Generally, consumers cannot control or even know the exact location of the provided resources, but can specify the location (such as country, state or data center) at a higher level of abstraction, so it is location-independent.
[0056] Rapid elasticity: The ability to quickly and elastically (sometimes automatically) deploy computing power to scale up quickly, and quickly release it to scale down quickly. To consumers, the computing power available for deployment often appears to be unlimited, and any amount of computing power can be accessed at any time.
[0057] Measurable services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.
[0058] The service model is as follows:
[0059] Software as a Service (SaaS): The capability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). Aside from limited user-specific application configuration settings, consumers neither manage nor control the underlying cloud infrastructure including networks, servers, operating systems, storage, or even individual application capabilities.
[0060] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired by consumers on the cloud infrastructure, which are created using programming languages and tools supported by the provider. Consumers neither manage nor control the underlying cloud infrastructure including networks, servers, operating systems or storage, but have control over the applications they deploy and may also have control over the configuration of the application hosting environment.
[0061] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, network, and other basic computing resources on which consumers can deploy and run arbitrary software including operating systems and applications. Consumers neither manage nor control the underlying cloud infrastructure, but have control over the operating system, storage, and applications they deploy, and may have limited control over selected network components (such as host firewalls).
[0062] The deployment model is as follows:
[0063] Private Cloud: Cloud infrastructure is run solely for an organization. The cloud infrastructure can be managed by the organization or a third party and can exist inside or outside the organization.
[0064] Community Cloud: A cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). A community cloud can be managed by multiple organizations within the community or by a third party and can exist inside or outside the community.
[0065] Public cloud: Cloud infrastructure is provided to the public or to large industry groups and is owned by an organization that sells cloud services.
[0066] Hybrid cloud: A cloud infrastructure consisting of two or more clouds (private, community or public) in a deployment model that remain distinct entities but are bound together by standardized or proprietary technologies (such as cloud burst sharing for load balancing between clouds) that enable data and application portability.
[0067] The cloud computing environment is service-oriented, with characteristics centered on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that includes a network of interconnected nodes.
[0068] See now Figure 4 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above (not shown). This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 1The types of computing devices 54A-N shown in are intended to be illustrative only, and computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and / or network addressable connection (eg, using a web browser).
[0069] See now Figure 5 , showing the cloud computing environment 50 ( Figure 4 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 5 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As described, the following layers and corresponding functions are provided:
[0070] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; servers based on RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage devices 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.
[0071] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75. Consistent with some embodiments of the present disclosure, virtual applications and operating systems 74 can operate based on CAUV.
[0072] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides cost tracking when resources are utilized within a cloud computing environment, and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management so that the required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-scheduling and procurement of cloud computing resources in anticipation of future demand according to the SLA.
[0073] The workload layer 90 provides examples of functions that can utilize a cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; mobile desktop 96.
[0074] The present invention may be a system, method, and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to execute various aspects of the present invention.
[0075] Computer readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as punch card or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses passing through fiber optic cables) or electrical signals emitted by wires.
[0076] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.
[0077] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages (such as Smalltalk, C++, etc.) and process programming languages (such as "C" programming languages or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can perform computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform various aspects of the present invention.
[0078] Aspects of the present invention are described herein with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.
[0079] These computer-readable program instructions can be provided to a processor of a computer, or other programmable data processing device to produce a machine, so that these instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which causes the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.
[0080] These computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so as to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, thereby causing the instructions executed on the computer, other programmable apparatus, or other device to implement the functions / actions specified in the flowchart and / or block diagram or multiple boxes.
[0081] The flowcharts and block diagrams in the accompanying drawings show the architecture, functions and operations of the possible implementations of the systems, methods and computer program products according to different embodiments of the present invention. To this end, each box in the flowchart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, the two boxes shown in succession can actually be completed as a step, and are executed simultaneously, substantially simultaneously, in a partially or completely overlapping manner in time, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.
[0082] The description of different embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein are selected to explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.
Claims
1. A method for managing program operations, the method comprising: detecting a hardware request of an application, wherein the application is executed on a virtualized computer system; determining that the hardware request includes a counter, wherein the counter is to be updated by the virtualized computer system, and wherein the counter includes a counter value; intercepting the hardware request before the hardware request is processed by a hypervisor hosting the virtualized computer system based on the determining that the hardware request includes the counter; storing the counter value in a secure memory, the secure memory being obfuscated to the hypervisor; generating a scrambled counter value; updating the hardware request using the scramble counter value; providing an updated hardware request to the hypervisor; detecting a response to the hardware request, the response provided by the hypervisor, wherein the response includes an updated scramble counter value; preventing said response; generating an update amount based on the updated scramble counter value and based on the scramble counter value; calculating an updated counter value based on the counter value and based on the update amount; as well as The updated counter value is provided to the application.
2. The method according to claim 1, comprising: determining one or more data inputs in the hardware request based on the detecting of the hardware request; as well as The one or more data inputs are obfuscated.
3. The method according to claim 1 or 2, wherein: The secure memory is encrypted, and wherein the secure memory is inaccessible to the hypervisor.
4. The method according to claim 1 or 2, wherein: The method is executed by a hypervisor.
5. The method according to claim 4, wherein: The scrambled counter value is generated by a random number generator of the hypervisor.
6. The method according to claim 1 or 2, further comprising: The scramble counter value is stored prior to providing the hardware request to the hypervisor.
7. The method according to claim 1 or 2, wherein: The counter is a decrementer.
8. A system for managing program operations, the system comprising: a memory containing one or more instructions; as well as a processor communicatively coupled to the memory, the processor being configured in response to reading the one or more instructions to: detecting a hardware request of an application, wherein the application is executed on a virtualized computer system; determining that the hardware request includes a counter, wherein the counter is to be updated by the virtualized computer system, and wherein the counter includes a counter value; intercepting the hardware request before the hardware request is processed by a hypervisor hosting the virtualized computer system based on the determining that the hardware request includes the counter; storing the counter value in a secure memory, the secure memory being obfuscated to the hypervisor; generating a scrambled counter value; updating the hardware request using the scramble counter value; providing an updated hardware request to the hypervisor; detecting a response to the hardware request, the response provided by the hypervisor, wherein the response includes an updated scramble counter value; preventing said response; generating an update amount based on the updated scramble counter value and based on the scramble counter value; calculating an updated counter value based on the counter value and based on the update amount; as well as The updated counter value is provided to the application.
9. The system according to claim 8, wherein: The processor is further configured to: Based on the detecting of the hardware request, determining one or more data inputs in the hardware request; and The one or more data inputs are obfuscated.
10. The system according to claim 8 or 9, wherein: in, The secure memory is encrypted, and wherein the secure memory is inaccessible to the hypervisor.
11. The system according to claim 8 or 9, wherein: The processor is configured to execute a hypervisor.
12. The system according to claim 11, wherein: The generating the scrambled counter value includes obtaining the scrambled counter value from a trusted platform module in communication with the hypervisor.
13. The system according to claim 8 or 9, further comprising: storing the scramble counter value before providing the hardware request to the hypervisor; identifying a response to the hardware request, the response provided by the hypervisor; determining that the response includes an updated scramble counter value, the updated scramble counter value being based on the scramble counter value; preventing said response; generating an update amount based on the updated scramble counter value and based on the scramble counter value; calculating an updated counter value based on the counter value and based on the update amount; as well as The updated counter value is provided to the application.
14. The system according to claim 8 or 9, wherein: The counter is a decrementer.
15. A computer program product for managing program operations, the computer program product comprising: A computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform the method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Virtual computer system and method for implementing data sharing between each field
CN101377745A
Method for switching between virtualized and non-virtualized system operation
CN103430185A
Hypervisor file system
US20110119669A1
Symmetric multiprocessing with virtual CPU and VSMP technology
US8539499B1
