• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The subject of the invention is a code execution system with blind hypervision mechanism, said system comprising: at least one addressable physical memory (203), a processor (200) operating in at least two modes, a mode known as initialization method for defining at least one partition in the memory and at least one second so-called nominal mode, a memory bus (204) connecting the processor to the memory, a memory partitioning unit (202) positioned on the memory bus (204) ), said unit being adapted to restrict the memory access to the partition being executed when the processor (200) is in a mode other than the initialization mode.
    公开号:FR3020160A1
    申请号:FR1453420
    申请日:2014-04-16
    公开日:2015-10-23
    发明作者:Philippe Dore；Emmanuel Ohayon；Renaud Sirdey
    申请人:Commissariat a lEnergie Atomique CEA；Commissariat a lEnergie Atomique et aux Energies Alternatives CEA；
    IPC主号:
    专利说明:

    [0001] The invention relates to a system for executing code with blind hypervision mechanism and applies to the field of computer security. Work on hardware architectures for security is numerous, the oldest dating back about 15 years. Many approaches exist, with different security objectives. A majority of them rely on hardware support in the form of a cryptographic coprocessor or a full virtual processor that ensures its isolation from the rest of the world, as in the case of ARMTM TrustZone technology. Another solution belonging to the state of the art is the XOM (eXecute-Only Memory) hardware architecture described in particular in the article by D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh J. Mitchell, and M. Horowitz, "Architectural Support for Copy and Tamper Resistant Software," SIGPLAN Not., Vol. 35, no. 11, pp. 168-177, Nov. 2000. 20 This technique offers confidentiality guarantees by allowing blind execution of application code, including possibly a complete virtual machine. The code and the data are stored in encrypted form in memory, and are encrypted / decrypted on the fly within the processor itself. Another existing solution is the AEGIS architecture described in the article by GE Suh, D. Clarke, B. Gassend, M. van Dijk, and S. Devadas entitled "AEGIS: Architecture for Tamper-evident and Tamperresistant Processing," In Proceedings of the 17th Annual International Conference on Supercomputing, New York, NY, USA, 2003, pp. 160-171. This architecture is based on the same principles but considers an even more severe threat model.
    [0002] However, there is a need to find an alternative to these solutions to achieve higher performance with lower hardware costs.
    [0003] One of the aims of the invention is to remedy the shortcomings / drawbacks of the state of the art and / or to make improvements thereto. For this purpose, the invention provides a code execution system with a blind hypervision mechanism, said system comprising: at least one addressable physical memory; a processor operating in at least two modes, a so-called initialization mode making it possible to define at least one partition in the memory and at least one second so-called nominal mode; a memory bus connecting the processor to the memory; - A memory partitioning unit positioned on the memory bus, said unit being adapted to restrict the memory access to the partition running when the processor is in a mode other than the initialization mode.
    [0004] One of the fundamental advantages of the system according to the invention is that it does not need to encrypt / decrypt on the fly the code and data flowing on the memory bus. Another advantage is that the invention makes it possible to avoid the use of Trusted Computed Base (TCB) code to secure the hypervisor.
    [0005] Other characteristics and advantages of the invention will become apparent with the aid of the description which follows given by way of nonlimiting illustration, with reference to the appended drawings in which: FIG. 1 gives an example of a distributed system using virtualization blindly ; FIG. 2 gives an example of a code execution system according to the invention; FIG. 3 schematically illustrates the various operating modes of a code execution system processor according to the invention; FIG. 4 gives an example of a state machine on which appear the possible operations that can be implemented on a partition via the virtual machine loader; Figure 5 illustrates an example of a loading protocol between the virtualization master (Virtualization Master) and a BHH. One of the objectives of the present invention is to guarantee the confidentiality and the integrity of the content of the memory used in a code execution platform when virtual machines are implemented. It is thus possible to guard against elevation of privilege type attacks. In other words, a malicious software that succeeds in executing with hypervisor rights by exploiting for example a security flaw is in practice unable to recover or modify codes and / or data virtualized machines due to the implementation of the invention. This is guaranteed inter alia by the addition of hardware elements in the system. With the implementation of the invention, only a physical attack implemented for example using a probe would defeat the security of the system. Thus, one of the decisive advantages of the invention is to be able to guarantee that the virtualization of machines does not bring additional vulnerability to those that could initially be present in virtualized machines. FIG. 1 gives an example of a system enabling virtualization blind. One of the objectives of the invention is to guarantee the confidentiality and integrity of the codes and data of one or more virtual machines running on a virtualization platform. The system of the invention implements a set of techniques to protect against threats that can be described using the following model: the threat is purely software; the purpose of the attack is to read or modify the codes and / or data of the partition of a virtual machine of the system; for this purpose, the attacker attempts to exploit a vulnerability in the virtualization system, by granting himself the rights of the hypervisor or by aiming at the exploitation of malicious code present in the hypervisor; the attack is therefore a priori from a virtual machine executed by the system; however, the present invention generally allows to guard against an attack from malicious code running in the hypervisor.
    [0006] The virtualization architecture (Figure 1) relies on a network of host machines 100-103 or BHH (Blind Hypervision Host) to run virtual machines. It thus relies on one or more machines called virtualization masters (Virtualization Master) 104 having a role of conductor and authentication authority. The network 105 connecting these machines is not considered safe. The virtualization master 104 is responsible for the load balancing between the different BHH hosts 100-103 and oversees the migration of virtual machines from one BHH 100-103 machine to another. He also emits a virtual machine for the first time to a BHH 100-103 machine when it is introduced into the system. Finally, it acts as an authentication authority for the various BHH 100-103 machines in order to secure virtual machine image exchanges. It should be noted that the functions of the virtualization master can be fulfilled by a server machine of the general public type without requiring any particular hardware. BHH host machines 100-103 run a hypervisor and receive from the network encrypted images of virtual machines to run. They can also receive migration commands from the virtualization master 104 and thus exchange images of virtual machines with each other. BHH machines require specific hardware components to implement blind hypervision. These components will be described in detail later. Each virtual machine is encrypted using a symmetric key of its own, chosen and maintained by the virtualization master 104. This will therefore communicate the encryption key to a machine BHH 100103 before it can execute the virtual machine, according to a key exchange protocol, an example of which is given later in this description. For authentication and encryption key exchange purposes, each BHH machine 100-103 has a unique private / public cryptographic key pair. The private key is stored in the machine BHH 100103 for example in a read-only register, but it is accessible by the processor only under certain conditions. In one embodiment, it can only be used by a component of the machine BHH 100-103 called virtual machine loader (VM Loader) whose role is precisely to load the virtual machine decrypted into memory for execution . The virtual machine loader (VM Loader) is also capable of the reverse operation, ie to encrypt a memory image of a virtual machine in order to send it through the network to another machine, on virtualization master order (Virtualization Master). The virtual machine loader (VM Loader) of a BHH 100-103 machine can be implemented in software and / or hardware, for example as a confidence code stored in memory or fully implemented by a DMA (Direct Memory Access). The VM Monitor (or hypervisor) runs on the BHH machine in a hypervisor mode of the processor, which paradoxically gives it few rights. This goes against conventional processor architectures for which the hypervisor mode is traditionally the most permissive. Such a mode notably allows full access to Memory Memory Unit (MPU) / Memory Management Unit (MMU) registers and i.o inputs / outputs (1 / 0s). In the context of the invention in particular, when the processor operates in hypervisor mode, it is impossible to read or write in the memory space allocated to the virtual machines. For this, a Memory Partitioning Unit is used. Access to a memory partition 15 allocated to a given virtual machine is allowed only when that same virtual machine is running. In one embodiment and when the processor is operating in hypervisor mode, access to memory is also possible when the virtual machine loader (VM Loader) is running. The hypervisor meanwhile can execute its scheduling algorithms and render possible services to its virtual machines without being able to access their memory, and without being able to grant them access rights over them. This isolation of the hypervisor is an essential aspect to guard against elevation privilege type attacks. In the nominal operating mode, the memory is therefore partitioned into different zones, and whose limits are fixed. These zones correspond to: a partition dedicated to the hypervisor, the UPM Memory Partitioning Unit ensuring that this partition 30 is the only accessible when the processor operates in hypervisor mode; - I 11 partitions dedicated to virtual machines, each of which can host a single machine, UPM Memory Partitioning Unit ensuring that each of these partitions is accessible only in user mode or supervisor of the corresponding virtual machine, or by the virtual machine loader (VM Loader) when loading / unloading the virtual machine; - optionally, a read-only partition that can not be modified for the virtual machine loader code (VM io Loader). In a preferred embodiment, the limits of these partitions are set at the initialization of the processor. In summary, the security properties of the system according to the invention are based on a set of hardware and / or software mechanisms detailed below: a UPM Memory Partitioning Unit physically providing memory isolation between the different partitions; a processor having various security features such as: four operating modes: Initialization, Hypervisor, Supervisor and User, with associated specific privileges; o macro-instructions allowing the transition from one mode to another, possibly accompanied by a simultaneous partition change in the UPM Memory Partitioning Unit; o in particular, a specific macro-instruction for saving the processor registers in memory 30 before switching it to hypervisor mode (similar in the spirit to INT or SYSENTER instructions IntelTm processors), while the Partitioning Unit UPM memory simultaneously switches to the partition dedicated to the hypervisor; a virtual machine loader (VM Loader) can also be used to perform transfers: o from the network interface to the memory with decryption of data on the fly; o From the memory to the network interface with encryption on the fly.
    [0007] Figure 2 gives an example of a code execution system according to the invention. The code execution system with blind hypervision mechanism comprises: at least one addressable physical memory 203; a processor 200 operating in at least two modes, a so-called initialization mode making it possible to define at least one partition in the memory and at least one second so-called nominal mode; a memory bus 204 connecting the processor to the memory; a memory partitioning unit 202 positioned on the memory bus 204, said unit being adapted to restrict the memory access to the partition being executed when the processor 200 is in a mode other than the initialization mode. According to an essential aspect of the invention, a dedicated hardware device provides memory isolation between the different partitions. Unlike a conventional MMU / MPU, this device can only be programmed when the processor is operating in Initialization mode. This means that neither the hypervisor nor a virtual machine will have read or write access to its registers and tables.
    [0008] This device is adapted to allow to define the size and the number of partitions in memory as well as the possible communication channels between the virtual machines and the hypervisor. In particular, it is able to verify that: - in nominal operation (that is to say outside initialization mode), one and only one partition is accessible: that of the hypervisor if the processor is running in hypervisor mode, or that of the running virtual machine. The conventional additional access rights io then apply only to the current partition, while the other partitions are inaccessible; - The selection of the appropriate partition is done automatically when the processor switches from hypervisor mode to a virtual machine or vice versa. is Partitions should be disjointed a priori and cover all the memory of the system. Nevertheless, this device may make it possible to define certain areas common to several partitions, such as, for example, access to input / output registers on devices shared between several virtual machines, or even communication buffers between a virtual machine. (VM) and the hypervisor. The UPM memory partitioning unit can be added to an effective classical address protection / translation mechanism (MPU / MMU) within the partition, and modifiable by the operating system of the partition (or the hypervisor in the case of the hypervisor partition). In an alternative embodiment, an address translation unit is attached to the system. This unit defines only partitions, upstream of a "classic" MMU on the memory bus. This translation unit can be limited to a segmentation-type mechanism such as on x86 [R11], that is to say to define memory segments by an offset and a size, each segment corresponding to a partition. Figure 2 gives an illustration of this type of implementation. In nominal operation, when the processor executing a VM accesses a memory word, it sends on the bus a virtual address in the active partition. The MMU, generally configured by the virtual machine (VM) operating system (OS), transforms this virtual address into an actual address within the partition. Then, the UPM memory partitioning unit converts this real address into a physical address of the host machine. The UPM memory partitioning unit may be preconfigured in a static way in the CPU design or at least configurable in initialization mode: the size of the partition dedicated to the hypervisor; - size of partitions that can accommodate a virtual machine (VM); 10 - the number of partitions assigned to the virtual machines can be deduced from the two parameters above. Extensions can be designed to allow the hypervisor to dynamically modify (out of boot mode) the size or number of partitions, provided that the codes and data thereof remain inaccessible to the hypervisor or other partitions . In one embodiment, the processor can implement four levels of execution: - initialization mode; - hypervisor mode; 20 - VM-supervisor mode; - VM-user mode. The hypervisor, VM-supervisor and VM-user modes are relatively similar to those found on architectures offering hardware support for virtualization. In particular, they have a decreasing priority in the sense of interruptions. For example, in VM-supervisor mode, the processor may have its execution interrupted to switch to hypervisor mode, either via an interrupt or via a dedicated instruction. Figure 3 schematically illustrates the different modes of operation of a code execution system processor according to the invention. Boot mode 300 is the default boot mode of the processor. It allows read / write access to all the contents of the memory, as well as to the configuration registers of the memory partitioning unit, but the functions of the virtual machine loader (VM Loader) are not available to it. accessible. This mode exists to allow initialization of the system and its input / output devices. It is possible to include in the system configuration the configuration of the partitioning of the memory. The processor can be used in a conventional manner while remaining in this mode. However, features related to secure virtualization will not be accessible. It is possible after initialization to switch to hypervisor mode thanks to a dedicated instruction LAUNCHHV processor. This switchover activates the security mechanisms and is irreversible. The LAUNCHHV instruction, available only in the Initialization mode, performs the following operations: - dump and invalidate the caches of data instructions; 15 - reset of the processor context (general registers, states, ...); - activation of memory partitioning; - Failover of the memory partitioning unit so that the visible memory is that of the partition containing the hypervisor; - Switching the processor to hypervisor mode; - loading the instruction pointer at the choice of the architecture options chosen (the two options are not exclusive): 25 o with the address immediately following the instruction LAUNCHHV (continue the execution flow during the transition initialization to processor hypervisor means that the initialization code of the platform resides in the memory area corresponding to the partition of the hypervisor and that the failover does not affect the address translation for that partition); with a fixed address in the partition of the hypervisor, corresponding to its entry point (the address of the hypervisor entry point corresponding to its activation during the initialization to hypervisor transition of the processor can be loaded indirectly via the reading of it at a fixed address and known of its partition). - during this transition and depending on the chosen implementation the partitions dedicated to hosting virtual machines will be: o erased and marked as free; o and / or simply marked as free and not erased. In the second case, the call to the vmlNewContext () primitive will have to clear the selected partition.
    [0009] Note that the only way to return to the Initialization mode after executing the LAUNCHHV instruction, and thus recover full power on the machine is a RESET of the processor, which will reset the registers and Memory. This mechanism will ensure the confidentiality of the data loaded by the virtual machine loader (VM Loader) in memory. Hypervisor mode 301 is the mode in which the hypervisor must execute. This is a full processor execution mode. According to the invention, it is impossible in this mode to directly access the partitions of the virtual machines, read or write. The manipulation of these partitions is done through the virtual machine loader (VM Loader), whose API is then accessible. Extensions can be considered to resize the memory partitions of virtual machines from the hypervisor mode, always provided that it can never access the memory. From the hypervisor mode, it is possible to start the execution of a virtual machine (VM) via a specific instruction LAUNCHVM, taking as parameter the identifier of the partition containing the virtual machine (VM) to be executed. In principle, this macro-instruction is similar to a "return of interruption" or "system callback" (eg SYSEXIT or IRET on x86 processors), insofar as it simultaneously makes it possible in particular to change the memory context, to restore the set of status registers corresponding to the virtual machine (VM), and to switch the processor in VM-Supervisor or VM-User mode, depending on the state of the restored virtual machine (VM).
    [0010] The VM-supervisor mode 303 corresponds to the traditional supervisor mode of any processor under hypervision. This is usually the execution mode used to execute the kernel code of virtual machines. For example, it should allow the guest operating system (OS) of the virtual machine (VM) to execute privileged instructions such as masking its interrupts, or modifying its address space within its partition ( MMU access). Nevertheless, it must remain physically impossible for the code executing at this level to access the partition of the hypervisor, or that of other virtual machines, thanks to the memory partitioning unit. VM-User mode 302 corresponds to the traditional user mode of any processor. Together with the VM-Supervisor mode, they constitute the two processor modes available for a virtual machine. Switching between these two modes is not mandatory and is the responsibility of the system software and the virtual machine. These mode changes take place within the partition of the virtual machine (VM) concerned and have no impact on security. Initializing or resetting the processor (RESET) is a delicate operation because it is the only method allowing the processor to switch to initialization mode. This simply means that partial RESET operations are proscribed. If the processor incorporates software reset means of the machine, they should adhere to the following recommendations: - VM-User mode: this type of instruction is not available in this mode; VM-Supervisor mode: such an instruction should simply restart the virtual machine by assigning the instruction pointer the address of its entry point; Hypervisor mode: the execution of such an instruction must behave identically to the assertion of the RESET pin of the processor, namely: erasing all the memory of the RAM type; o invalidation of data and instruction caches; o reset the processor context (general registers, states, ...); o deactivation of all memory protections and deletion of MPU / MMU tables (including the configuration of the Memory Partitioning Unit); o RESET of all input / output devices; o Failover of the processor into Initialization mode, thus rendering the virtual machine loader (VM Loader) inaccessible; o loading the instruction pointer with the address of the RESET vector. Initialization mode: the memory does not contain any sensitive data in clear, so it is possible to perform a "simplified" RESET, for example without resetting the contents of the RAM. The application of the same mechanisms as during a RESET from the Hypervisor mode is obviously sufficient.
    [0011] There is no particular assumption on the VM Monitor (hypervisor): it can be a priori any hypervisor, provided to modify it to be able to comply with the memory protection imposed by the Memory Partitioning Unit. In particular, remember that the hypervisor can access directly neither read nor write to the memory of virtual machines. Any communication needs between the virtual machines and the hypervisor may be provided by isolated and dedicated shared memory channels, clearly identified in the memory partitioning unit during the initialization phase. The virtual machine loader (VM Loader) is a service called by the hypervisor, and whose role is to make data transfers to (respectively from) the memory partition of a VM with decryption (respectively encryption) on the fly . It should be remembered that these areas are inaccessible for reading and writing from the hypervisor mode.
    [0012] The Virtual Loader (VM Loader) is the only entity that has access to the BHH private key. It is therefore the only one able to authenticate with the master of virtualization 104, and to receive confidential data from it using this same key.
    [0013] The virtual machine loader (VM Loader) can optionally be implemented physically, in the form of a DMA (Direct Memory Access) for example and / or software. This device provides in hypervisor mode an API (Application Programming Interface), a basic example of which is described below.
    [0014] Figure 4 gives an example of a state machine on which appear the possible operations that can be implemented on a partition via the VM Loader. When the VM Loader is in a state other than IDLE 400 for a given partition, the partition can not be executed. This is the case in WRITE 401 and READ 402 read modes. Otherwise, executing a LAUNCHVM instruction would throw an exception retrieved by the hypervisor. Examples of primitives are given below.
    [0015] Example primitive: vmlNewContext () Syntax: vmlNewContext (cipherKey) This primitive returns a free memory partition identifier in which a virtual machine (VM) can be loaded. This partition is fully reset by the virtual machine loader (VM Loader) during the call. The call fails if all partitions are used. The cipherKey parameter corresponds to the encryption key of the virtual machine (VM) that is about to be loaded, which is itself encrypted using the VM Loader public key (which is therefore indecipherable typically by hypervisor). The virtual machine loader (VM Loader) decrypts and loads this key into a virtual machine key register (VM) that is unique to it, and which is inaccessible to the rest of the machine; it will be used for on-the-fly encryption / decryption of this partition during vmlWriteContext () and / or vmlReadContext () operations. It should be noted that there must be a VM key registry per partition. In an implementation where all the partitions dedicated to the execution of a virtual machine (VM) are of identical size, this primitive does not require any additional parameter. It could, however, be easily generalized by accepting as input the desired partition size. For performance purposes the partition status (erased or not) could be stored in a virtual machine loader (VM Loader) register io accessible only by the latter. Example of a primitive: vmlWriteContext () Syntax: vmlWriteContext (id, data, size) 15 This primitive decrypts and writes to the memory partition identified by id, the encrypted data block of size data. The memory partition identifier has been previously obtained using the vmlNewContext () primitive. The decryption is done using the symmetric key that was passed during the call to vmlNewContext H. The behavior of this primitive is similar to the POSIX write () semantics: every call to vmlWriteContext () writes adjacent blocks in the partition until it is full, in which case the call to this primitive fails. Primitive example: vmlCloseContext () Syntax: vmlCloseContext (id, CRC) This primitive signals the end of writing a partition, and proceeds to a verification of the data written in the partition with an error detection code CRC type. The verification is performed on the decrypted data. The verification concerns the whole of the partition thus making it possible to protect against the replay (to write pieces of different virtual machines).
    [0016] After the call to this primitive it becomes impossible to add new data via a call to vmlWriteContext (). The partition must be freed thanks to the vmlDeleteContext () primitive. If the check fails, the primitive returns an error code. Therefore: - the erroneous virtual machine (VM) can not be executed; - the partition can not be completed by other calls to the vm1WriteContext (); - The vmlCloseContext () primitive can not be called again with a different CRC; t pr.m. the primitive ve vm1Delet - I i i vmlDeleteContext () should be used to free and erase the partition. Example primitive: vmlExportContext () Syntax: vmlExportContext (id, destldentity) This primitive is used to initiate a transfer of the virtual machine for migration. The destldentity parameter is provided by the virtualization master (Virtualization Master) and tells the VM Loader which BHH to send the image to the encrypted virtual machine (VM). Primitive example: vmlReadContext () Syntax: vmlReadContext (id, data, size) This primitive reads in the memory partition identified by id, the chunk block 30 of data data of size size. This memory partition has been previously loaded with the virtual machine targeted by the migration. The behavior of this primitive is similar to the semantics of the POSIX read (): each call to vmlReadcontext 0 reads successively adjacent blocks in the partition, until it is read in its entirety, in which case the call to this primitive fails. The data thus recovered from the partition are encrypted on the fly by using the virtual machine (VM) encryption key obtained during the call to vmlNewContext () and stored until now in an internal register to the virtual machine loader. (VM Loader). The recipient virtual machine loader (VM Loader) will only be able to decrypt the sent image if the virtualization master (Virtualization Master) has also previously sent the encryption key associated with the virtual machine (VM), via a call vmlNewContext 0. io Primitive Example: vmlTerminateContext () Syntax: vmlTerminateContext (id, crc) This primitive signals the end of a partition export, and proceeds to generate and issue the CRC type integrity check code. . This code relates to all the decrypted data contained in the data partition. After the call to this primitive, the memory of the partition is completely erased and can be allocated again, similarly to a call vmlDeleteContext 0. Example primitive: vmlDeleteContext () Syntax: vmlDeleteContext (id) 25 This primitive frees the partition identified by id. The contents of the associated memory are completely erased. This partition can later be reallocated by the hypervisor using the vmlNewContext () primitive. The virtual machine loader (VM Loader) can be implemented in software form, provided that its code and data are protected from any interaction with other partitions (including the hypervisor). To avoid malicious code injection, the virtual machine loader (VM Loader) can be loaded into memory using SecureBoot techniques from the Unified Extensible Firmware Interface Forum (IUEFI) to ensure its authenticity. In addition, the virtual machine loader (VM Loader) will have to run in a clean partition, which will give it access to the partitions of the virtual machines it loads or unloads. It should be noted that this partition can take several forms: memory area reserved and protected in nominal operating mode of the processor, secure virtual machine type "TrustZone" or other. Calling functions of the Virtual Machine Loader API (VM io Loader) can only be done by the processor running in hypervisor mode; in addition, a call to one of these functions will temporarily disable the UPM memory partitioning unit to allow access to other partitions by the virtual machine loader (VM Loader). Processor mechanisms that can be implemented to provide the switchover between the hypervisor mode and any virtual machine (VM) are described herein. Switching to a virtual machine (VM) The processor can have a dedicated LAUNCHVM instruction that takes as argument the identifier of the virtual machine (VM) to execute, as returned by the call vmlNewContext 0. This instruction is available 25 only in hypervisor mode, and returns an error if it is executed on a partition that has not been validated by a call to vmlCloseContext O. The LAUNCHVM instruction performs the following operations: - dump and invalidation of instruction and data caches; 30 - reset of the processor context (general registers, states, ...); - Switching the Memory Partitioning Unit so that the visible memory is that of the partition containing the virtual machine (VM); 35 - switchover of the processor into VM-Supervisor mode; - loading instruction pointer with a fixed address inside the active partition corresponding to the context restore routine. The address of the context restore routine may be indirectly loaded by reading it to a fixed address known to the active partition. The code of the context restore routine is provided by the hypervisor and must be included by the virtual machine at the specified address. Its role is to restore the processor context of the previously preempted virtual machine. It should be noted that the alteration of this code by the virtual machine will have no impact on the rest of the system and will in no way compromise the confidentiality of the data of said virtual machine (VM). In addition, the data of the other virtual machines and the hypervisor present on the host machine will not be compromised in any way. On the other hand, the VM whose restoration code has been altered may in any case no longer function correctly, or even no longer work at all; but such a denial of service attack corresponds to a fault inherent in the virtual machine (VM) itself, which we do not claim to protect by the present invention. Virtual machine (VM) that makes the hand A virtual machine (VM) can give the hand to choose via a dedicated instruction 25 YIELD (corresponding to what is commonly called a "hypercall"), or occurrence of a non-maskable interruption signaling the expiration of a timer programmed by the hypervisor. These two situations lead to the same behavior: execution in VM-Supervisor mode of a context-saving procedure (registers, state of the machine, ...) "hard-wired", or at least stored unalterably in the system; - dump and invalidation of instruction and data caches; - Reset the processor context (general registers, 35 states, ...); - configuration of the MPU so that the visible memory is that of the partition containing the hypervisor; - Switching the processor to hypervisor mode; - loading the instruction pointer with a fixed address inside the partition hosting the hypervisor corresponding to a dedicated entry point of the latter. The address of the entry point dedicated to the return to the hypervisor can be indirectly loaded by reading it at a fixed address and known to the partition intended for it. It should be noted that the code of the context backup routine can not reside within the virtual machine (VM) itself. It would then be impossible to guarantee that this routine ends well with a switch to the hypervisor; therefore, a denial of service attack affecting the entire system (and thus the other virtual machines running on it) could easily be operated. Therefore, the context backup routine of the virtual machine (VM) must be provided either by microcode, or by code stored in a non-corrupted area of the processor, or by any other mechanism internal to the processor ensuring its unalterability. Exchanges of virtual machines with the outside It is considered essentially inputs / outputs (1 / 0s) 25 corresponding to network traffic passing through one or more shared interfaces; but the principles extend to all other types of I / Os, such as writes to a disk shared between multiple virtual machines. Many hypervisor implementations require virtual machines to go through the hypervisor for their I / O operations, particularly on architectures not benefiting from hardware virtualization tools (IOMMU). The assumption is made here that for any outgoing communication, data security (including confidentiality, authenticity) must be guaranteed by the virtual machine in the upper layers of the implemented protocol, whatever it may be. This in itself does not constitute an additional security flaw due to virtualization, since a compromised hypervisor spying out the 1 / 0s of a virtual machine (VM) would have the same nuisance power as any network node. of communication through which the 1/0 in question flows. Note that this precaution is necessary even if the virtual machine (VM) is allowed as part of its partition to directly address physical input / output devices, as long as they are shared with the hypervisor and / or d other virtual machines.
    [0017] Loading and Migrating Virtual Machine (VM) The introduction of a new virtual machine into the system is done by the virtualization master (Virtualization Master). This associates with each new virtual machine (VM) a unique encryption key, which will be used for the transit of the virtual machine (VM) through the network. The virtualization master (Virtualization Master) thus maintains: - a list of the public keys of the BHH network; a list of the (symmetrical) encryption keys associated with each virtual machine (VM) running in the system; - When the virtualization master (Virtualization Master) chooses to send the image of a virtual machine (VM) to a BHH for execution, it sends him first the encryption key of the virtual machine (VM), it is encrypted using the BHH public key, so that only the VM Loader can read it through a vmlNewContext () call. Follows the image of the virtual machine (VM) itself, encrypted with the encryption key transmitted.
    [0018] Figure 5 illustrates an example of a load protocol between the virtualization master (Virtualization Master) and a BHH. The function E is any encryption function; the expression Ei <(X) corresponds to the encryption of X using the key K. BHHO_pub is the public key of the VM loader of BHHO, and Kvmo is the symmetric encryption key associated with the VMO. Note that no clear data passes into the hands of the hypervisor of the BHHO: all decryptions are made by the virtual machine loader (VM Loader), in areas inaccessible to the hypervisor.
    [0019] The virtual machine (VM) migration from a BHHO to a BHH1 follows a similar protocol: the virtualization master (Virtualization Master) sends to BHH1 the encryption key K (itself encrypted with the public key BHH1 pub) of the virtual machine (VM) that it is expected to receive, and then sends the command to the sending BHH (BHHO) to initiate the migration. This sends the encrypted virtual machine (VM) to BHH1 using the key Kvm05 previously stored in a Virtual Machine Loader (VM Loader) virtual machine key (VM) registry. It should be noted that the protocols described here are partial and given only by way of example; they can be extended (with the features of the virtual machine loader (VM Loader)) notably to reinforce the BHH authentication by the virtualization master (Virtualization Master), to ensure for example that a malicious machine does not attempt It is important to note that the invention can be applied in different contexts than the virtualization one DSPs (Digital Signal Processors) Signal Processors (DSPs) are used to execute "fake" virtual machines to a BHH of the network. or in a general way the specialized processors (used for example as accelerators) present in the embedded world do not necessarily have very advanced MPU / MMU devices.for a given application, they efficiently perform intensive computing operations. such as radio signal, image or sound processing, the coexistence of several virtual machines as well as These are not requirements for these types of processors. Nevertheless, it may be advantageous to offer this type of CPU a blind loading mechanism in order to guarantee the confidentiality of the loaded application. This possibility is in addition to Secure Boot type techniques that guarantee the authenticity of the loaded application. Only a subset of the mechanisms described in this document will then be required: the vmlExportContext (), vmlReadContext () and vmlTerminateContext () primitives are not necessary; - two partitions are needed (one for the charger and one for the application); - three processor modes are sufficient (Initialization, Loader and Application, only the InitializationCharger, theApplicableLoader transitions are allowed, assuming that once in nominal mode the application no longer needs to execute the charger code again. It could even be considered to allow the Application partition to recover the memory space of the Loader partition.It is possible to reduce to two the number of processor modes for a DSP if, at its design, the size of the two partitions, that this mechanism is active at startup and that the application performs the initialization of the platform A typical use would be to: - start the processor in initialization mode, initialize the machine (peripherals, I / O) and prepare the partitions , in particular by loading the bootloader in the memory zone corresponding to the partition Charger, - execute the InitializationChargeur transition, thus activating the Unit Partitioning Memory and flipping the processor to the Loader partition; - Execute the loader code, which relies on the VM Loader to load the code of the application into its partition - the loader can not read the code of the application that is loaded in memory ; - execute the Application Loader transition, in order to launch the application. The machine will remain in the application partition until RESET.
    [0020] The functionalities of the BHH can be implemented in a pseudo-distributed way, for example on a chip of many-core type where several clusters are connected by a NoC (Network-on-Chip). In such a configuration, each partition can be materialized by a node of the network, de facto implementing a certain level of isolation since each cluster has its own memory. As before, the virtual machine loader (VM Loader) can be implemented by security code on the hypervisor cluster, and / or by a dedicated DMA type hardware, able in both cases to write to the memory from any cluster / partition to load the decrypted image of a virtual machine (VM). Note that if the virtual machine loader (VM Loader) relies on the NoC, it should be considered trusted because images of virtual machines can a priori circulate in clear. In other words, it is necessary to guarantee (for example materially) that the other clusters of the chip can not spy on the data circulating therein. In this architecture, the mode changes from / to Hypervisor are no longer necessary since a cluster is entirely dedicated to hypervision; nevertheless the non-hypervisor partitions must be able to be interrupted by the hypervisor partition for the migrations / loading of 20 virtual machines. Note finally that this principle can be generalized to a distributed implementation between several physical machines connected by a private subnet; once again, this can be considered under the assumption that the nodes of the subnet are not able to spy the frames running on it (images "in clear" from the virtual machine loader).
    权利要求:
    Claims (10)
    [0001]
    CLAIMS1- A code execution system with a blind hypervision mechanism, said system comprising: - at least one addressable physical memory (203); a processor (200) operating in at least two modes, a so-called initialization mode making it possible to define at least one partition in the memory and at least one second so-called nominal mode; a memory bus (204) connecting the processor to the memory; a memory partitioning unit (202) positioned on the memory bus (204), said unit being adapted to restrict the memory access to the partition being executed when the processor (200) is in a mode other than the mode initializing.
    [0002]
    2- System according to claim 1 wherein a memory partition is allocated to a hypervisor and at least one memory partition is allocated to at least one virtual machine (VM).
    [0003]
    3. System according to one of the preceding claims wherein the instruction set of the processor (200) is adapted so that the transition to initialization mode is not possible once the nominal mode has been activated.
    [0004]
    4- System according to one of the preceding claims comprising a virtual machine loader for loading into memory (203) a virtual machine for execution, said virtual machine being encrypted and having been transmitted by a telecommunications network, said loader virtual machine comprising a digital key of its own and allowing it to decrypt the virtual machine.
    [0005]
    5. System according to claim 4 wherein the virtual machine loader is implemented in hardware form with a silicon module, its cryptographic key being etched in the silicon.
    [0006]
    6. System according to one of claims 4 or 5 wherein the processor (200) comprises a hypervisor mode (301), access to the physical memory being exceptionally possible when the virtual machine loader is executed.
    [0007]
    7. System according to one of the preceding claims comprising a MMU memory management unit (201) positioned between the processor (200) and the memory partitioning unit (202).
    [0008]
    8. System according to one of the preceding claims comprising an MPU memory protection unit positioned between the processor and the memory partitioning unit.
    [0009]
    9. System according to one of the preceding claims wherein the physical memory (203) is partitioned into a plurality of zones when the processor (200) is in nominal mode, these areas corresponding to: a partition dedicated to a hypervisor, memory partitioning unit ensuring that this partition is the only accessible when the processor operates in hypervisor mode; - I 11 partitions dedicated respectively to N virtual machines, each of which can host a single machine, the UPM Memory Partitioning Unit ensuring that each of these partitions is only accessible in a user mode or a supervisory mode of the corresponding virtual machine , or by the virtual machine loader when loading / unloading the virtual machine.
    [0010]
    The system of claim 9 wherein the physical memory (203) comprises a non-modifiable read-only partition for the code of a virtual machine loader.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3132375B1|2020-09-23|System for executing code with blind hypervision mechanism
    JP6402034B2|2018-10-10|System and method for keeping information in a computer safe
    US8938782B2|2015-01-20|Systems and methods for providing network access control in virtual environments
    Nanavati et al.2014|Cloud security: A gathering storm
    Li et al.2011|A trusted virtual machine in an untrusted management environment
    US7073059B2|2006-07-04|Secure machine platform that interfaces to operating systems and customized control programs
    Rutkowska et al.2010|Qubes OS architecture
    TWI498768B|2015-09-01|A computer system comprising a secure boot mechanism, a method for starting a computer system, and a central processing unit
    Borders et al.2009|Protecting Confidential Data on Personal Computers with Storage Capsules.
    US20090319782A1|2009-12-24|Interconnectable personal computer architectures that provide secure, portable, and persistent computing environments
    US20120265975A1|2012-10-18|Microcontroller with Embedded Secure Feature
    WO2015183117A1|2015-12-03|Below-os security solution for distributed network endpoints
    Chan et al.2008|Bootjacker: compromising computers using forced restarts
    Skillen et al.2013|Deadbolt: locking down android disk encryption
    Rutkowska2015|Intel x86 considered harmful
    US20190384923A1|2019-12-19|Mechanism to enable secure memory sharing between enclaves and i/o adapters
    Zhao et al.2016|Hypnoguard: Protecting secrets across sleep-wake cycles
    Dubrulle et al.2015|Blind hypervision to protect virtual machine privacy against hypervisor escape vulnerabilities
    US10592678B1|2020-03-17|Secure communications between peers using a verified virtual trusted platform module
    Kim et al.2019|hTPM: Hybrid implementation of trusted platform module
    Aarseth2015|Security in cloud computing and virtual environments
    US10614231B1|2020-04-07|Integrated out-of-band security for high security embedded systems
    WO2020247924A1|2020-12-10|Systems and methods for processor virtualization
    Koutroumpouchos2019|A security evaluation of TrustZone based trusted execution environments
    Sensaoui2020|An In-Depth Study and Implementation of Protection Mechanisms For Embedded Devices Running Multiple Applications
    同族专利:
    公开号 | 公开日
    EP3132375B1|2020-09-23|
    US20170032119A1|2017-02-02|
    EP3132375A1|2017-02-22|
    WO2015158821A1|2015-10-22|
    FR3020160B1|2017-08-11|
    US10095862B2|2018-10-09|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP1681630A1|2005-01-14|2006-07-19|Intel Corporation|Virtualizing physical memory in a virtual machine system|
    WO2012148324A1|2011-04-26|2012-11-01|Telefonaktiebolaget Lm Ericsson |Secure virtual machine provisioning|
    US7689801B2|2007-08-29|2010-03-30|International Business Machines Corporation|Method for distributing hypervisor memory requirements across logical partitions|
    US7730248B2|2007-12-13|2010-06-01|Texas Instruments Incorporated|Interrupt morphing and configuration, circuits, systems and processes|
    US8127086B2|2008-06-06|2012-02-28|International Business Machines Corporation|Transparent hypervisor pinning of critical memory areas in a shared memory partition data processing system|
    US9152200B2|2009-06-23|2015-10-06|Hewlett-Packard Development Company, L.P.|Resource and power management using nested heterogeneous hypervisors|
    US9928091B2|2010-09-30|2018-03-27|Microsoft Technology Licensing, Llc|Techniques for streaming virtual machines from a server to a host|
    US8849941B2|2010-09-30|2014-09-30|Microsoft Corporation|Virtual desktop configuration and operation techniques|
    US8607054B2|2010-10-15|2013-12-10|Microsoft Corporation|Remote access to hosted virtual machines by enterprise users|
    US8832686B2|2010-10-29|2014-09-09|Microsoft Corporation|Inherited product activation for virtual machines|
    US8924964B2|2010-11-01|2014-12-30|Microsoft Corporation|Dynamic allocation and assignment of virtual environment|
    CN103430185B|2011-03-22|2016-10-26|瑞典爱立信有限公司|For the method for switching between virtualization system operation and non-virtualized system operation|
    US9792136B2|2011-04-28|2017-10-17|Microsoft Technology Licensing, Llc|Hardware assisted inter hypervisor partition data transfers|
    WO2014122414A1|2013-02-05|2014-08-14|Arm Limited|Handling memory access operations in a data processing apparatus|
    WO2015008112A1|2013-07-18|2015-01-22|Freescale Semiconductor, Inc.|System on chip and method therefor|US9826030B1|2015-06-04|2017-11-21|Amazon Technologies, Inc.|Placement of volume partition replica pairs|
    US9826041B1|2015-06-04|2017-11-21|Amazon Technologies, Inc.|Relative placement of volume partitions|
    DE102015210539A1|2015-06-09|2016-12-15|Robert Bosch Gmbh|Memory protection unit, memory management unit and microcontroller|
    US9785783B2|2015-07-23|2017-10-10|Ca, Inc.|Executing privileged code in a process|
    US10003554B1|2015-12-22|2018-06-19|Amazon Technologies, Inc.|Assisted sideband traffic management|
    US9952890B2|2016-02-29|2018-04-24|Red Hat Israel, Ltd.|Kernel state data collection in a protected kernel environment|
    EP3551753A4|2016-12-09|2020-10-07|The Broad Institute, Inc.|Crispr effector system based diagnostics|
    US10509733B2|2017-03-24|2019-12-17|Red Hat, Inc.|Kernel same-page merging for encrypted memory|
    US10209917B2|2017-04-20|2019-02-19|Red Hat, Inc.|Physical memory migration for secure encrypted virtual machines|
    US10379764B2|2017-05-11|2019-08-13|Red Hat, Inc.|Virtual machine page movement for encrypted memory|
    法律状态:
    2016-04-28| PLFP| Fee payment|Year of fee payment: 3 |
    2017-04-28| PLFP| Fee payment|Year of fee payment: 4 |
    2018-04-26| PLFP| Fee payment|Year of fee payment: 5 |
    2019-04-29| PLFP| Fee payment|Year of fee payment: 6 |
    2020-04-30| PLFP| Fee payment|Year of fee payment: 7 |
    2021-04-29| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1453420A|FR3020160B1|2014-04-16|2014-04-16|SYSTEM FOR EXECUTING A CODE WITH BLIND HYPERVISION MECHANISM|FR1453420A| FR3020160B1|2014-04-16|2014-04-16|SYSTEM FOR EXECUTING A CODE WITH BLIND HYPERVISION MECHANISM|
    PCT/EP2015/058263| WO2015158821A1|2014-04-16|2015-04-16|System for executing code with blind hypervision mechanism|
    EP15716534.1A| EP3132375B1|2014-04-16|2015-04-16|System for executing code with blind hypervision mechanism|
    US15/124,642| US10095862B2|2014-04-16|2015-04-16|System for executing code with blind hypervision mechanism|
    [返回顶部]