Patent application number | Description | Published |
20080307419 | Lazy kernel thread binding - Various technologies and techniques are disclosed for providing lazy kernel thread binding. User mode and kernel mode portions of thread scheduling are decoupled so that a particular user mode thread can be run on any one of multiple kernel mode threads. A dedicated backing thread is used whenever a user mode thread wants to perform an operation that could affect the kernel mode thread, such as a system call. For example, a notice is received that a particular user mode thread running on a particular kernel mode thread wants to make a system call. A dedicated backing thread that has been assigned to the particular user mode thread is woken. State is shuffled from the user mode thread to the dedicated backing thread using a state shuffling process. The particular kernel mode thread is put to sleep. The system call is executed using the dedicated backing thread. | 12-11-2008 |
20080313647 | Thread virtualization techniques - Various technologies and techniques are disclosed for virtualizing threads. An operating system thread is virtualized by intercepting accesses of the operating system thread state and emulating a normal operating system behavior. A kernel mode thread state is virtualized by intercepting kernel accesses of the kernel mode thread state and emulating a normal kernel mode behavior. A user mode thread state is virtualized by intercepting user mode accesses of the user mode thread state and emulating a normal user mode behavior. If the access is a write access, then the write access is applied to a virtual thread structure. If the access is a read access, then the read access is applied to the virtual thread structure. | 12-18-2008 |
20080313652 | Notifying user mode scheduler of blocking events - Various technologies and techniques are disclosed for detecting and handling blocking events. A user mode thread is assigned a dedicated backing thread. System calls are made on the dedicated backing thread. The kernel detects when a system call results in a blocking event. A core that the dedicated backing thread is currently running on is observed. An entry in a per process table that maps cores to a currently associated primary thread waiting to be woken is consulted. The currently associated primary thread for the core is woken with a special result code to indicate that it was woken due to the blocking system call. The primary thread is released back to the application. A user mode scheduler is notified of the blocking event so a core can continue to be utilized. | 12-18-2008 |
20080313656 | User mode stack disassociation - Various technologies and techniques are disclosed for allowing a user mode stack to be shared by multiple contexts. A user mode stack can be shared between execution contexts that are guaranteed to not need the user mode stack at the same time. For example, each user mode portion of a kernel thread is provided with a dedicated backing thread. When a respective dedicated backing thread is sleeping and not using a respective user mode stack, the user mode stack is allowed to float with a respective user mode portion to other kernel threads. The user mode stack is disassociated from the kernel portion of the thread. The kernel is notified of an address of a user mode thread context. The kernel mode portion of the converted thread becomes a backing thread that waits. The user mode portion of the converted thread can be switched without entering the kernel. | 12-18-2008 |
20080320475 | Switching user mode thread context - Various technologies and techniques are disclosed for switching user mode thread context. A user mode portion of a thread can be switched without entering a kernel by using execution context directly based on registers. Upon receiving a request to switch a user mode part of a thread to a new thread, user mode register contexts are switched, as well as a user mode thread block by changing an appropriate register to point at the user mode thread block of the new thread. Switching is available in environments using segment registers with offsets. Each user mode thread block in a process has a descriptor in a local descriptor table. When switching a user mode thread context to a new thread, a descriptor is located for a user mode thread block of the new thread. A shadow register is updated with a descriptor base address of the new thread. | 12-25-2008 |
20090164749 | COUPLED SYMBIOTIC OPERATING SYSTEMS - A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments. | 06-25-2009 |
20090292919 | SECURE EXECUTION ENVIRONMENT ON EXTERNAL DEVICE - A device, such as a smartcard, may be externally-connected to a host platform and may be used to enhance or extend security services provided by the host platform's Trusted Platform Module (TPM). The device and the platform exchange keys in order to facilitate reliable identification of the platform by the device and vice versa, and to support cryptographic tunneling. A proxy component on the host device tunnels information between the platform and the device, and also provides the device with access to the TPM's services such as sealing and attestation. The device can provide secure services to the platform, and may condition provision of these services on conditions such as confirming the platform's identity through the exchanged keys, or platform state measurements reported by the TPM. | 11-26-2009 |
20090313397 | Methods and Systems for Protecting Data in USB Systems - The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected. | 12-17-2009 |
20110119500 | SAVING AND RETRIEVING DATA BASED ON PUBLIC KEY ENCRYPTION - In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using public key encryption, in a manner that allows the data to be obtained from the ciphertext only if one or more conditions are satisfied. In accordance with another aspect, a bit string is received from a calling program. Data in the bit string is decrypted using public key decryption and returned to the calling program only if one or more conditions included in the bit string are satisfied. | 05-19-2011 |
20110119501 | SAVING AND RETRIEVING DATA BASED ON PUBLIC KEY ENCRYPTION - In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using public key encryption, in a manner that allows the data to be obtained from the ciphertext only if one or more conditions are satisfied. In accordance with another aspect, a bit string is received from a calling program. Data in the bit string is decrypted using public key decryption and returned to the calling program only if one or more conditions included in the bit string are satisfied. | 05-19-2011 |
20110119502 | SAVING AND RETRIEVING DATA BASED ON PUBLIC KEY ENCRYPTION - In accordance with certain aspects, bound key operations on ciphertext and/or data are implemented. A bound key operation can receive both data to be signed and a bound key blob that is bound to one or more processors, recover a private key from the bound key blob, and generate a digital signature over the data using the private key. A bound key operation can alternatively receive both ciphertext and a bound key or bound key structure bound to one or more processors, recover or reconstruct a private key based on the bound key or bound key structure, and use the private key to generate plaintext corresponding to the ciphertext. | 05-19-2011 |
20110119505 | SAVING AND RETRIEVING DATA BASED ON PUBLIC KEY ENCRYPTION - In accordance with certain aspects, data is received and a digital signature is generated and output. The digital signature can be a digital signature of the data and one or more conditions that are to be satisfied in order for the data to be revealed, or a digital signature over data generated using a private key associated with a bound key that is bound to one or more processors. | 05-19-2011 |
20110154057 | SAVING AND RETRIEVING DATA BASED ON PUBLIC KEY ENCRYPTION - In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using public key encryption, in a manner that allows the data to be obtained from the ciphertext only if one or more conditions are satisfied. In accordance with another aspect, a bit string is received from a calling program. Data in the bit string is decrypted using public key decryption and returned to the calling program only if one or more conditions included in the bit string are satisfied. | 06-23-2011 |
20110265097 | COUPLED SYMBIOTIC OPERATING SYSTEM - A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments. | 10-27-2011 |
20110307888 | PROTECTION OF VIRTUAL MACHINES EXECUTING ON A HOST DEVICE - Technology is described for protection of virtual machines executing on a host device having host processors and host memory. The system can include a hypervisor configured to enable the virtual machines to execute concurrently on the host device. An emancipated partition can be provided with a communication channel to the hypervisor. A primary partition can be configured to interface with the emancipated partition through the communication channel via the hypervisor. In addition, an emancipated memory space and virtual register state for the emancipated partition can be protected from direct access by the primary partition. | 12-15-2011 |
20120166816 | Auxiliary Functionality for Pixel Data - The various methods and systems described herein are directed to supplying a secure channel for software executing on a host computer. The methods and systems address and provide solutions for an attack model in which rogue software executing on the host computer attempts to inappropriately obtain or otherwise manipulate data. Some embodiments can provide pixel data that can be kept confidential (in that untrusted software applications cannot read the data off of the display screen). In addition, other embodiments can preserve the integrity of the pixel data by detecting whether the pixel data has been inappropriately manipulated. Various embodiments are based on a decryption engine that is located on a video card very late in the video processing chain such that programmatic access to decrypted pixel data is denied. | 06-28-2012 |
20120331550 | TRUSTED LANGUAGE RUNTIME ON A MOBILE PLATFORM - Disclosed is a trusted language runtime (TLR) architecture that provides abstractions for developing a runtime for executing trusted applications or portions thereof securely on a mobile device (e.g., a smartphone). TLR offers at least two abstractions to mobile developers: a trustbox and a trustlet. The trustbox is a runtime environment that offers code and data integrity, and confidentiality. Code and data running inside a trustbox cannot be read or modified by any code running outside the trustbox. A trustlet is the code portion of an application that runs inside a trustbox. With TLR, programmers can write applications in .NET and specify which parts of the application handle sensitive data, and thus, run inside the trustbox. With the TLR, the developer places these parts in a trustlet class, and the TLR provides all support needed to run the parts in the trustbox. | 12-27-2012 |
20130054948 | Attestation Protocol for Securely Booting a Guest Operating System - In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode. | 02-28-2013 |
20130282934 | Methods and Systems for Protecting Data in USB Systems - The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected. | 10-24-2013 |
20140059680 | LOCAL SECURE SERVICE PARTITIONS FOR OPERATING SYSTEM SECURITY - Systems and methods provide multiple partitions hosted on an isolation technology such as a hypervisor where at least one of the partitions, a local secure service partition (LSSP), provides security services to other partitions. The service partitions (LSSPs) host those high assurance services that require strict security isolation, where the service can be shared across partitions and accessed even when the user is not connected to a network. The LSSP also can certify the results of any computation using a key signed by a TPM attestation identity key (AIK), or other key held securely by the hypervisor or a service partition. The LSSPs may be configured to provide trusted audit logs, trusted security scans, trusted cryptographic services, trusted compilation and testing, trusted logon services, and the like. | 02-27-2014 |
20140258700 | DYNAMICALLY LOADED MEASURED ENVIRONMENT FOR SECURE CODE LAUNCH - A “Secure Code Launcher” establishes platform trustworthiness, i.e., a trusted computing base (TCB), and uses hardware or firmware based components to securely launch one or more software components. The Secure Code Launcher measures and loads software components by interfacing with security extension functionality integral to one or more hardware or firmware-based components in the computing device. For example, various embodiments of the Secure Code Launcher include firmware-based components that interface with security extension functionality integral to the computing device to measure and load boot managers, operating system (OS) loaders, or other OS components including OS kernels. Similarly, the Secure Code Launcher is capable of measuring and loading software components responsible for installing an instance of an OS. In addition, various embodiments of the Secure Code Launcher provide a hypervisor loader that measures and loads a hypervisor which in turn measures and loads operating system components including virtual machines. | 09-11-2014 |
20140359270 | ATTESTATION PROTOCOL FOR SECURELY BOOTING A GUEST OPERATING SYSTEM - In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode. | 12-04-2014 |
20150078550 | SECURITY PROCESSING UNIT WITH CONFIGURABLE ACCESS CONTROL - A security processing unit is configured to manage cryptographic keys. In some instances, the security processing unit may comprise a co-processing unit that includes memory, one or more processors, and other components to perform operations in a secure environment. A component that is external to the security processing unit may communicate with the security processing unit to generate a cryptographic key, manage access to a cryptographic key, encrypt/decrypt data with a cryptographic key, or otherwise utilize a cryptographic key. The external component may comprise a central processing unit, an application, and/or any other hardware or software component that is located outside the security processing unit. | 03-19-2015 |