WO2013074071A1 - Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties - Google Patents

Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties Download PDF

Info

Publication number
WO2013074071A1
WO2013074071A1 PCT/US2011/060621 US2011060621W WO2013074071A1 WO 2013074071 A1 WO2013074071 A1 WO 2013074071A1 US 2011060621 W US2011060621 W US 2011060621W WO 2013074071 A1 WO2013074071 A1 WO 2013074071A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
application
physical memory
access
computer
Prior art date
Application number
PCT/US2011/060621
Other languages
English (en)
Inventor
Harshawardhan Vipat
Ravi Sahita
Roshni CHATTERJEE
Madhukar Tallam
Original Assignee
Intel Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Priority to PCT/US2011/060621 priority Critical patent/WO2013074071A1/fr
Priority to US13/653,077 priority patent/US8726404B2/en
Publication of WO2013074071A1 publication Critical patent/WO2013074071A1/fr
Priority to US14/272,440 priority patent/US9292679B2/en
Priority to US15/042,838 priority patent/US10073986B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/145—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being virtual, e.g. for virtual blocks or segments before a translation mechanism
    • 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/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/151—Emulated environment, e.g. virtual machine

Definitions

  • Embodiments of the present invention relate generally to the technical field of data processing, and more particularly, to regulating access to and protecting different portions of an application of a virtual machine that reside in different portions of physical memory.
  • Hierarchal protection domains in some cases referred to as “protection rings,” may be implemented and enforced by hardware to protect data and functionality of a computer system.
  • a kernel may execute with a high level of hardware privilege known as "Ring-0”
  • device drivers may execute with intermediate levels of hardware privilege known as “Ring-1 " and “Ring-2”
  • user-mode applications may execute with a lowest level of hardware privilege known as “Ring-3.”
  • malware Computer code or instructions that cause undesirable and/or malicious operations or results may sometimes be referred to as "malware.”
  • Some malware may be configured to, when executed, use stealth to avoid detection by virus scanners and other security tools. Such malware may be referred to as a "rootkit.”
  • Some user-mode rootkits may exploit user-mode (e.g., Ring-3) processes or applications to hide themselves and steal sensitive user information such as passwords, online banking credentials, and data received from web pages.
  • User-mode rootkits may function in a variety of ways. Some rootkits may inject code or instructions intended to execute undesirable and/or malicious operations into an executing application. Some rootkits may alter a code path of an application to force execution of code or instructions that may cause undesirable and/or malicious operations.
  • Pages of virtual memory used by applications executing in virtual machines may be mapped to physical memory of a host in various ways.
  • guest linear or virtual addresses (“GVA”) may be mapped to host physical addresses with the aid of a guest page table ("GPT").
  • An operating system of a virtual machine sometimes referred to as a "guest” operating system, may set up and maintain the GPT and may also set a page directory base register (“PDBR") to point to the base of the GPT.
  • PDBR page directory base register
  • a processor of the host machine may use PDBR to find the GPT and may follow the GPT to locate a particular page.
  • a GVA alone may not be sufficient to uniquely identify a page containing code or data.
  • a GVA may be unique only in the context of a particular virtual machine application, and may need to be added to a CR3 to find a particular page of the application.
  • Extended page tables may be available as part of VT-x2 technologies, provided by Intel ® .
  • a GPT may map GVA to guest physical addresses (“GPA”), and the EPT may map GPA to host physical addresses.
  • GPA guest physical addresses
  • a processor or processor core may first use CR3 to find the GPT. The processor may then follow the GPT to find the GPA. Then, the processor may utilize an EPTP field in a virtual machine control structure ("VMCS") to find an appropriate EPT. Last, the processor may use the EPT to locate the actual host physical address.
  • VMCS virtual machine control structure
  • the permissions contained in an EPT may be enforced by hardware in an operating system-independent manner. When a violation of these permissions occurs, control may be passed to the virtual machine manager, which may intervene and take further action.
  • FIG. 1 schematically illustrates an example of how portions of a computer program of a virtual machine may be mapped from virtual memory to physical memory, in accordance with various embodiments.
  • FIG. 2 schematically depicts an example of how various components may cooperate to protect memory and portions of applications from malicious code, in accordance with various embodiments.
  • FIGs. 3-4 schematically depict an example method that may be implemented by a virtual machine manager, in accordance with various embodiments.
  • FIG. 5 schematically depicts an example method that may be implemented by an anti-malware agent, in accordance with various embodiments.
  • FIG. 6 schematically depicts an example system on which various disclosed methods may be implemented, in accordance with various embodiments.
  • a computer-implemented method may include a plurality of instructions configured to provide an apparatus, in response to execution of the instructions by the apparatus, with a virtual machine manager, wherein the virtual machine manager is configured to selectively employ different views with different permissions to map guest physical memory of a virtual machine of the apparatus to host physical memory of the apparatus, to regulate access to and protect different portions of an application of the virtual machine that resides in different portions of the physical memory.
  • the different views may be implemented using extended page tables.
  • systems and methods may also be disclosed that perform these operations.
  • phrase “A and/or B” means (A), (B), or (A and B).
  • phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).
  • module may refer to, be part of, or include an Application Specific Integrated Circuit (“ASIC"), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
  • ASIC Application Specific Integrated Circuit
  • instructions or computer code may be "malicious” if they cause or have the ability to cause an apparatus and/or computer system to perform unintended, undesired and/or malicious operations.
  • known advertising malware, viruses, rootkits, spyware, Trojan horses and worms all may be considered malicious, and may be “blacklisted.”
  • code or instructions that are known not to cause unintended, undesirable or malicious operations may be referred to herein as "white listed.”
  • FIG. 1 depicts schematically how, in accordance with various embodiments, an application 10 of a virtual machine 1 1 may be loaded into operating system virtual memory 12 and mapped from kernel virtual memory 12 to guest physical memory 14 using a guest page table ("GPT") 13. Guest physical memory 14 may in turn be mapped to host physical memory 16 using one or more extended page tables (“EPT”) 15.
  • GPT guest page table
  • EPT extended page tables
  • a hypervisor or virtual machine manager (“VMM”) 18, which in VMX may operate in a special privilege mode, "VMX root,” may regulate access to and protect different portions of application 10 of the virtual machine that resides in different portions of physical memory 16.
  • virtual machine manager 18 may be configured to selectively employ different views 20 (in Fig. 1 , "EPT 1 " and "EPT 2") to map guest physical memory 14 to host physical memory 16.
  • a "view” may be a permissions map for physical pages of a guest operating system.
  • one or more views may be implemented using extended page tables. For example, a view may be an instance of an extended page table.
  • a first of the different views 20, such as EPT 1 may permit access to a portion of application 10 in a first portion 22 of host physical memory 16.
  • first portion 22 may include main().
  • EPT 1 which permits read and execute access ("RX") to first portion 22, may be employed initially so that execution of main() of application 10 may be initiated.
  • EPT 1 also may limit or prohibit access to a portion of application 10 in a second portion 24 of host physical memory 16.
  • EPT 1 provides read only ("RO") access to second portion 24, which stores data and code portions 26 and 28, respectively, of application 10. Accordingly, while EPT 1 is in use, data portion 26 cannot be altered and code portion 28 cannot be executed.
  • a view may prohibit all access, including read access, to particular portions of physical memory.
  • a second of the different views, EPT 2 may limit or prohibit access to first portion 22 of host physical memory 16 containing main() but permit access to second portion 24 of physical memory 16.
  • EPT 2 may provide read-write access ("RW”) to data portion 26 and RX access to code portion 28 of application 10. Accordingly, while EPT 2 is in use, data portion 26 may be altered and code portion 28 may be executed.
  • RW read-write access
  • virtual machine manager 18 may be configured to determine, during operation, that a portion of application 10 in a portion (e.g., 22, 26, 28) of physical memory 16 to which access is limited under a current view is to be accessed, e.g., for writing or execution.
  • EPT 1 may be in use when execution of application 10 passes main() in first portion 222 to code portion 28 of application 10, which is not executable under EPT 1 .
  • An EPT violation may cause control to pass to virtual machine manager 18.
  • Virtual machine manager 18 may selectively employ another view, such as EPT 2, that permits appropriate access to code portion 28.
  • virtual machine manager 18 may point the EPTP field in a virtual machine control structure ("VMCS") to EPT 2, in order to make EPT 2 current.
  • VMCS virtual machine control structure
  • a view may be selectively employed based at least in part on whether instructions being executed (or to be executed) to access the portion of application 10 will cause malicious activity or operations to occur. Such instructions may be referred to herein as "malicious instructions.”
  • virtual machine manager 18 may be configured to compare the instructions being executed or to be executed to instructions known to be malicious.
  • virtual machine manager 18 may be configured to take various actions. For example, virtual machine manager 18 may store in a log an indication of whether a particular view was employed, or if access to a portion of an application was denied because code to be executed was determined to be malicious. In some embodiments, virtual machine manager 18 may notify an anti-malware agent (see Fig. 2) executing on virtual machine 1 1 when the instructions being executed or to be executed are determined to be malicious. The anti-malware agent may then take further action.
  • an anti-malware agent see Fig. 2
  • a computer system 100 may include one or more virtual machines 102.
  • Virtual machine 102 may include a guest operating system to facilitate execution of one or more applications 1 10.
  • Application 1 10 may include various portions, including but not limited to data portions (e.g., stored in 26 in Fig. 1 ), code portions (e.g., stored in 22, 28 in Fig. 1 ), import address tables ("IAT"), libraries (e.g., dynamic link-libraries, or "DLLs”), and so forth. Portions of application 1 10 may be loaded into, fixed and/or locked into to pages of guest physical memory (e.g., 14 in Fig. 1 ) of virtual machine 102.
  • data portions e.g., stored in 26 in Fig. 1
  • code portions e.g., stored in 22, 28 in Fig. 1
  • IAT import address tables
  • libraries e.g., dynamic link-libraries, or "DLLs”
  • an application of a virtual machine such as application 1 10 may also include an application-level anti-malware agent ("AM Agent").
  • AM Agent application-level anti-malware agent
  • the application level AM Agent may be delegated by another component (e.g., Anti-malware agent 132 described below) to carry out intra- application detection and remediation operations.
  • user- mode applications such as application 1 10 may execute with a relatively low privilege level that, compared to other privilege levels, provides fewer privileges, such as hardware privilege level Ring-3, for Intel® Architecture embodiments.
  • virtual machine 102 may include a kernel 130 and an anti-malware agent 132.
  • Anti-malware agent 132 may exchange information with kernel 130 and other components as described below. Kernel 130 and anti-malware agent 132 may execute in accordance with a privilege level that provides more privileges than the privilege level of application 1 10, such as hardware privilege level Ring-0, for Intel® Architecture embodiments.
  • Computer system 100 may also include one or more virtual machine management-level applications executing outside virtual machine 102, e.g. with VMX root privileges. These management applications may include a view manager 140 and an anti-malware handler 142, either of which may be part of a virtual machine manager 1 18. In various embodiments, view manager 140 may maintain views and view associations, as well as switch between views based on the view associations when requested. [0031 ] An example of how these components may operate in order to regulate access to portions of an application of a virtual machine will now be described. Anti-malware agent 132 may operate similarly to an operating system driver, and may register a callback with kernel 130 for loading/unloading of application 1 10.
  • an "Application Load Notification" or other similar communication may be received by anti-malware agent 132 at arrow 200, e.g., via a callback from kernel 130.
  • Anti-malware agent 132 may exercise admission control based on measurement and verification of application pages or based on some other policy.
  • Anti-malware agent 132 may then perform various tasks.
  • anti-malware agent 132 may fix or lock pages of application 1 10 in guest physical memory (e.g., 14 of Fig. 1 ) at arrow 202. Fixing or locking pages of application 1 10 in guest physical memory may ensure that the guest operating system does not swap out a portion (e.g., code or data) of application 1 10 in a protected portion of physical memory with something else.
  • Anti-malware agent 132 may create various views to map guest physical memory of virtual machine 102 to host physical memory (e.g., 16 in Fig. 1 ). The different views may be selectively employed, e.g., by virtual machine manager 1 18 and/or view manager 140, to regulate access to and protect different portions of application 1 10 of virtual machine 102 that reside in different portions of physical memory. In various embodiments, to ensure that portions of virtual machine applications such as application 1 10 are not accessible from other applications, views may be created on a per-application basis.
  • anti-malware agent 132 may provide to anti-malware handler 142 a plurality of associations between a page directory base register ("PDBR") and a plurality of views created by anti-malware agent 132.
  • PDBR page directory base register
  • anti-malware handler 142 or view manager 140 may store these PDBR-to-view associations in a table 144. For example, in Fig. 2, three views are created for a first application which starts at CR3A, and two views are associated with a second application that starts at CR3B.
  • anti-malware handler 142 may retrieve a view associated with application 1 10 (e.g., using the current PDBR) and make the view active. Thereafter, when attempts are made to access portions of physical memory (e.g., to write or execute) to which access is limited or prohibited, an EPT violation may occur. This may cause control to be passed from application 1 10 to anti-malware handler 142.
  • Anti-malware handler 142 may be configured to selectively employ a different view of a plurality of different views associated with an application (see, e.g., 144) of the virtual machine to map guest physical memory of a virtual machine of the apparatus to host physical memory of the apparatus. This may regulate access to and protect different portions of the application that resides in different portions of the physical memory.
  • malware code may attempt to access (e.g., write to or execute) portions of physical memory to which access is limited or prohibited under a current view.
  • anti-malware handler 142 may determine that the code to be executed will cause or could cause malicious activity or operations, and may decline to switch to another view that would permit access to the requested pages.
  • anti-malware handler 142 may inform anti-malware agent 132 (or the intra-application anti- malware agent) of the violation.
  • anti-malware handler 142 may log the violation and/or a course of action taken by anti-malware handler 142 in response to the violation.
  • anti-malware handler may provide the log to anti-malware agent 132.
  • anti-malware handler 142 may also monitor the GPT mapping (e.g., 13 in Fig. 1 ) between guest virtual memory (e.g., 12 in Fig. 1 ) and guest physical memory (e.g., 14 in Fig. 1 ) to avoid a so-called copy on write, or "COW," attack.
  • GPT mapping e.g., 13 in Fig. 1
  • guest virtual memory e.g., 12 in Fig. 1
  • guest physical memory e.g., 14 in Fig. 1
  • COW copy on write
  • An operating system may share DLL's in memory and may only copy pages when an application writes to a page. When writing to a page, a guest virtual address of a DLL page that is copied to a different location in host physical memory may not change. However, the guest physical address of the DLL page may change.
  • Some malware therefore may include code that induces an operating system to write malicious code to the DLL page.
  • anti-malware agent 132 may receive notification and may perform memory clean up using a callback routine.
  • FIG. 3-4 An example method 300 that may be implemented by a virtual machine manager such as virtual machine managers 18 or 1 18 is depicted in Figs. 3-4.
  • the virtual machine manager may create views for each VM application that may be executed on a particular VM.
  • the virtual machine manager may store an association between a control register (e.g., CR3) and the views created at 302.
  • a control register e.g., CR3
  • the virtual machine manager may use a first view to map guest physical memory of a virtual machine to physical memory of a host.
  • the first view may permit access to a first portion of an application in a first portion of the physical memory, but may limit or prohibit access to a second portion of the application in a second portion of the physical memory.
  • the virtual machine manager may detect an attempt to access the second portion of the virtual machine application to which access is limited or prohibited under the first view. In other words this attempt may violate access permissions for the second portion of the virtual machine application.
  • the virtual machine manager may at this point invoke the AM handler (e.g., 142) to determine whether to permit the access and/or perform remediation.
  • the AM handler and/or virtual machine manager may determine whether to permit the access. For example, the AM handler may determine whether computer code being executed (or to be executed) to access the second portion of the virtual machine application is malicious. This may be done in various ways. For example, the AM handler may compare computer code being executed or to be executed to known malicious computer code, such as might be found in an online database or in a local database that is updated periodically.
  • the virtual machine manager and/or view manager may, based at least in part on a result of the determination of block 310, conditionally switch to use a second view to map virtual memory of the virtual machine to physical memory.
  • the second view may limit or prohibit access to the first portion of the application, but permit access to the second portion of the application. If the computer code being executed or to be executed is not malicious, the virtual machine manager and/or view manager may switch to the second view.
  • the virtual machine manager may detect an attempt to access to the first portion of the virtual machine application, access to which is limited or prohibited under the second view.
  • the virtual machine manager and/or AM handler e.g., 142
  • the virtual machine manager and/or AM handler may determine whether to permit the access. In various embodiments, this may be done in similar ways as at block 310.
  • the virtual machine manager and/or AM handler may, based at least in part on a result of the determination at block 312, conditionally switch to use the first view to map virtual memory of the virtual machine to physical memory, similar to block 312.
  • FIG. 5 An example method 500 that may be implemented by an anti- malware agent such as 132 in Fig. 2 is shown in Fig. 5.
  • the anti-malware agent may fix or lock portions of the application to guest physical memory (e.g., 14 in Fig. 1 ).
  • the anti-malware agent may create two or more views for the virtual machine application. While two views are described in the examples herein, this is not meant to be limiting, and any number of views may be created as appropriate.
  • the anti-malware agent may create two views: a trusted view and an untrusted view.
  • permissions for all pages may be set to both write and execute (e.g., RWX), which means there would be no access control when a guest operating system uses this view.
  • RWX write and execute
  • all the pages may be set to RO.
  • the anti-malware agent may provide, to a virtual machine manager such as 18 or 1 18, respective associations between the virtual machine application and the first and second views (see, e.g., 144 in Fig. 2).
  • the guest operating system may initiate execution of the application using the untrusted view.
  • Access to trusted data and functions may be limited or prohibited by the untrusted view.
  • an EPT violation may occur because the page containing the trusted function may be marked RO in untrusted view.
  • Control may be transferred to the virtual machine manager, which may validate the call, change context and may selectively employ the trusted view to permit execution of the called trusted function.
  • the anti-malware agent may receive notification of the closure, e.g., from the kernel.
  • the anti-malware agent may then perform memory cleanup using its callback routine.
  • FIG. 6 illustrates, for various embodiments, an example system 600 comprising one or more processor(s) 604 (e.g., a processor core), system control logic 608 coupled to at least one of the processor(s) 604, non-transitory computer- readable storage medium such as system memory 612 coupled to system control logic 608, non-transitory computer-readable storage medium such as non-volatile memory (“NVM”)/storage 616 coupled to system control logic 608, and one or more communications interface(s) 620 coupled to system control logic 608.
  • processor(s) 604 e.g., a processor core
  • system control logic 608 coupled to at least one of the processor(s) 604
  • non-transitory computer- readable storage medium such as system memory 612 coupled to system control logic 608
  • non-transitory computer-readable storage medium such as non-volatile memory (“NVM”)/storage 616 coupled to system control logic 608
  • communications interface(s) 620 coupled to system control logic 608.
  • System control logic 608 may include any suitable interface controllers to provide for any suitable interface to at least one of the processor(s) 604 and/or to any suitable device or component in communication with system control logic 608.
  • System control logic 608 may include one or more memory controller(s) to provide an interface to system memory 612.
  • System memory 612 may be used to load and store data and/or instructions, for example, for system 600.
  • System memory 612 for one embodiment may include any suitable volatile memory, such as suitable dynamic random access memory (“DRAM”), for example.
  • DRAM dynamic random access memory
  • System control logic 608 for one embodiment may include one or more input/output (“I/O") controller(s) to provide an interface to NVM/storage 616 and communications interface(s) 620.
  • I/O input/output
  • NVM/storage 616 may be used to store data and/or instructions, for example.
  • NVM/storage 616 may include any suitable non-volatile memory, such as flash memory, for example, and/or may include any suitable non-volatile storage device(s), such as one or more hard disk drive(s) ("HDD(s)”), one or more solid-state drive(s), one or more compact disc (“CD”) drive(s), and/or one or more digital versatile disc (“DVD”) drive(s), for example.
  • HDD(s) hard disk drive
  • CD compact disc
  • DVD digital versatile disc
  • the NVM/storage 616 may include a storage resource physically part of a device on which the system 600 is installed or it may be accessible by, but not necessarily a part of, the device.
  • the NVM/storage 616 may be accessed over a network via the communications interface(s) 620.
  • Communications interface(s) 620 may provide an interface for system 600 to communicate over one or more networks and/or with any other suitable device. Communications interface(s) 620 may include any suitable hardware and/or firmware.
  • System memory 612 and NVM/storage 616 may include temporal and persistent copies of a virtual machine manager 624, respectively.
  • the virtual machine manager 624 may include instructions that when executed by at least one of the processor(s) 604 result in the system 600 regulating access to and protecting portions of applications residing in physical memory, as earlier described.
  • the virtual machine manager 624 may additionally/alternatively be located in the system control logic 608.
  • At least one of the processor(s) 604 may be packaged together with logic for one or more controller(s) of system control logic 608.
  • at least one of the processor(s) 604 may be packaged together with logic for one or more controllers of system control logic 608 to form a System in Package ("SiP").
  • SiP System in Package
  • at least one of the processor(s) 604 may be integrated on the same die with logic for one or more controller(s) of system control logic 608.
  • at least one of the processor(s) 604 may be integrated on the same die with logic for one or more controller(s) of system control logic 608 to form a System on Chip (“SoC").
  • SoC System on Chip
  • the system 600 may be a desktop or laptop computer, a mobile telephone, a smart phone, a tablet, a set-top box, a game console, or any other device adapted to compile a computer program.
  • system 600 may have more or less components, and/or different architectures.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Storage Device Security (AREA)

Abstract

On décrit ici des modes de réalisation d'appareils, de procédés mis en œuvre sur ordinateur, de systèmes et de supports lisibles par ordinateur pour un gestionnaire de machine virtuelle, le gestionnaire de machine virtuelle étant configuré pour utiliser sélectivement différentes vues avec des permissions différentes pour mettre en correspondance une mémoire physique d'invité d'une machine virtuelle de l'appareil avec une mémoire physique hôte de l'appareil, afin de réguler les accès et de protéger les différentes parties d'une application de la machine virtuelle qui réside dans différentes parties de la mémoire physique. D'autres modes de réalisation peuvent être décrits et/ou revendiqués.
PCT/US2011/060621 2011-11-14 2011-11-14 Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties WO2013074071A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/US2011/060621 WO2013074071A1 (fr) 2011-11-14 2011-11-14 Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties
US13/653,077 US8726404B2 (en) 2011-11-14 2012-10-16 Regulating access to and protecting portions of applications of virtual machines
US14/272,440 US9292679B2 (en) 2011-11-14 2014-05-07 Regulating access to and protecting portions of applications of virtual machines
US15/042,838 US10073986B2 (en) 2011-11-14 2016-02-12 Regulating access to and protecting portions of applications of virtual machines

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2011/060621 WO2013074071A1 (fr) 2011-11-14 2011-11-14 Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties

Publications (1)

Publication Number Publication Date
WO2013074071A1 true WO2013074071A1 (fr) 2013-05-23

Family

ID=48429990

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2011/060621 WO2013074071A1 (fr) 2011-11-14 2011-11-14 Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties

Country Status (1)

Country Link
WO (1) WO2013074071A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105612528A (zh) * 2013-09-17 2016-05-25 微软技术许可有限责任公司 虚拟机的虚拟安全模式

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060161719A1 (en) * 2005-01-14 2006-07-20 Bennett Steven M Virtualizing physical memory in a virtual machine system
US20060206687A1 (en) * 2005-03-08 2006-09-14 Microsoft Corporation Method and system for a second level address translation in a virtual machine environment
US20100161875A1 (en) * 2008-12-10 2010-06-24 International Business Machines Corporation Simulator and simulating method for running guest program in host
US20100241785A1 (en) * 2006-04-27 2010-09-23 Vmware, Inc. Management of host physical memory allocation to virtual machines with a balloon application

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060161719A1 (en) * 2005-01-14 2006-07-20 Bennett Steven M Virtualizing physical memory in a virtual machine system
US20060206687A1 (en) * 2005-03-08 2006-09-14 Microsoft Corporation Method and system for a second level address translation in a virtual machine environment
US20100241785A1 (en) * 2006-04-27 2010-09-23 Vmware, Inc. Management of host physical memory allocation to virtual machines with a balloon application
US20100161875A1 (en) * 2008-12-10 2010-06-24 International Business Machines Corporation Simulator and simulating method for running guest program in host

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105612528A (zh) * 2013-09-17 2016-05-25 微软技术许可有限责任公司 虚拟机的虚拟安全模式

Similar Documents

Publication Publication Date Title
US10073986B2 (en) Regulating access to and protecting portions of applications of virtual machines
KR102189296B1 (ko) 가상 머신 보안 어플리케이션을 위한 이벤트 필터링
US10241819B2 (en) Isolating data within a computer system using private shadow mappings
CN107066311B (zh) 一种内核数据访问控制方法与系统
US9465700B2 (en) System and method for kernel rootkit protection in a hypervisor environment
US11847206B2 (en) Technologies for untrusted code execution with processor sandbox support
US8694738B2 (en) System and method for critical address space protection in a hypervisor environment
KR101946982B1 (ko) 가상 머신에서 멀웨어 탐지를 위한 프로세스 평가
US9405570B2 (en) Low latency virtual machine page table management
KR101536486B1 (ko) 오퍼레이팅 시스템(ｏｓ) 독립 안티-바이러스(ａｖ) 스캐너에 대해 강제적 보안 정책을 시행하기 위한 방법 및 장치
US8990934B2 (en) Automated protection against computer exploits
KR100681975B1 (ko) 가상머신 구조에서 게스트 소프트웨어의 동작 동안발생하는 폴트 제어
RU2513909C1 (ru) Ограничение областей памяти для считывания команд в зависимости от аппаратного режима и флага безопасности
US20120216281A1 (en) Systems and Methods for Providing a Computing Device Having a Secure Operating System Kernel
CN109583190B (zh) 监控进程的方法和装置
US10108800B1 (en) ARM processor-based hardware enforcement of providing separate operating system environments for mobile devices with capability to employ different switching methods
US11782744B2 (en) Data processing system and method for accessing data in the data processing system
AU2017201037A1 (en) Hypervisor-based interception of memory accesses
US10747686B2 (en) Method and system for co-privileged security domains
WO2013074071A1 (fr) Régulation de l'accès à des parties d'applications de machines virtuelles et protection de ces parties
Suzaki et al. Kernel memory protection by an insertable hypervisor which has VM introspection and stealth breakpoints
Shen et al. InversOS: Efficient Control-Flow Protection for AArch64 Applications with Privilege Inversion
RU2609761C1 (ru) Способ выполнения кода в режиме гипервизора
WO2015052829A1 (fr) Dispositif, procédé et programme de gestion d'informations
WO2023061607A1 (fr) Régulation d'accès à la mémoire

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11875747

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11875747

Country of ref document: EP

Kind code of ref document: A1