Abstract: A trusted virtualization platform protects sensitive customer data during operation of virtual machines in a multi-tenant cloud computing center. The trusted virtualization platform limits administrator access to the data and state of the virtual machines running thereon, reports any changes made thereto, and requires keys provided by the customer or a trusted third party of the customer to perform management operations on the virtual machines. By requiring cloud computing centers to use such trusted virtualization platforms, customers uploading their virtual machines into the cloud computing center can be assured that cloud administrators will not be able to access or tamper with their private data. Furthermore, customers can directly audit all important state or configuration changes for their virtual machines as the trusted virtualization platform can be configured to report all such changes according to a security policy set by the customer.

Abstract: A constraint is inserted into a program to address a vulnerability of the program to attacks. The constraint includes a segment of code that determines when the program has been asked to execute a “corner case” which does not occur in normal operations. The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. Optionally, the detector can be employed without the remediator for analysis. The context of the program can be saved and restored if necessary to continue operating after remediation is performed. The constraints can include descriptors, along with machine instructions or byte code, which indicate how the constraints are to be used.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: A trusted virtualization platform protects sensitive customer data during operation of virtual machines in a multi-tenant cloud computing center. The trusted virtualization platform limits administrator access to the data and state of the virtual machines running thereon, reports any changes made thereto, and requires keys provided by the customer or a trusted third party of the customer to perform management operations on the virtual machines. By requiring cloud computing centers to use such trusted virtualization platforms, customers uploading their virtual machines into the cloud computing center can be assured that cloud administrators will not be able to access or tamper with their private data. Furthermore, customers can directly audit all important state or configuration changes for their virtual machines as the trusted virtualization platform can be configured to report all such changes according to a security policy set by the customer.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: A runtime system using thread-shared code caches is provided which avoids brute-force all-thread-suspension and monolithic global locks. In one embodiment, medium-grained runtime system synchronization reduces lock contention. The system includes trace building that combines efficient private construction with shared results, in-cache lock-free lookup table access in the presence of entry invalidations, and a delayed deletion algorithm based on timestamps and reference counts. These enable reductions in memory usage and performance overhead.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: A constraint is inserted into a program to address a vulnerability of the program to attacks. The constraint includes a segment of code that determines when the program has been asked to execute a “corner case” which does not occur in normal operations. The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. Optionally, the detector can be employed without the remediator for analysis. The context of the program can be saved and restored if necessary to continue operating after remediation is performed. The constraints can include descriptors, along with machine instructions or byte code, which indicate how the constraints are to be used.

Abstract: Hijacking of an application is prevented by monitoring control flow transfers during program execution in order to enforce a security policy. At least three basic techniques are used. The first technique, Restricted Code Origins (RCO), can restrict execution privileges on the basis of the origins of instruction executed. This distinction can ensure that malicious code masquerading as data is never executed, thwarting a large class of security attacks. The second technique, Restricted Control Transfers (RCT), can restrict control transfers based on instruction type, source, and target. The third technique, Un-Circumventable Sandboxing (UCS), guarantees that sandboxing checks around any program operation will never be bypassed.