Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: An automated method to verify a block record for a digital ledger involves a first validation node (FVN) which receives a block record from a second validation node (SVN). The block record comprises a digital signature for the block record. In response to receiving the block record, the FVN automatically obtains a node identifier for the SVN, based on the digital signature for the block record. The first validator node uses the node identifier for the SVN to determine whether the SVN belongs to a validation group that comprises the FVN. The FVN uses an attestation service to determine whether the node identifier for the SVN belongs to a node with a trusted processor. The FVN determines whether the digital signature for the block record was created with a private key that corresponds to the node identifier for the SVN.

Abstract: In an embodiment, a method is provided. The method includes managing user-level threads on a first instruction sequencer in response to executing user-level instructions on a second instruction sequencer that is under control of an application level program. A first user-level thread is run on the second instruction sequencer and contains one or more user level instructions. A first user level instruction has at least 1) a field that makes reference to one or more instruction sequencers or 2) implicitly references with a pointer to code that specifically addresses one or more instruction sequencers when the code is executed.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: An automated method to verify a block record for a digital ledger involves a first validation node (FVN) which receives a block record from a second validation node (SVN). The block record comprises a digital signature for the block record. In response to receiving the block record, the FVN automatically obtains a node identifier for the SVN, based on the digital signature for the block record. The first validator node uses the node identifier for the SVN to determine whether the SVN belongs to a validation group that comprises the FVN. The FVN uses an attestation service to determine whether the node identifier for the SVN belongs to a node with a trusted processor. The FVN determines whether the digital signature for the block record was created with a private key that corresponds to the node identifier for the SVN. Other embodiments are described and claimed.

Abstract: Embodiments of apparatuses, methods, and systems for modifying the behavior of a guest installed to run within a VM are disclosed. In one embodiment, an apparatus includes virtualization logic, first storage, second storage, decode logic, and multiplexing logic. The virtualization logic is to provide a mode in which to operate a virtual machine. The first storage is to store a first plurality of micro-instructions to control the apparatus. The second storage is to store a second plurality of micro-instructions to control the apparatus. The decode logic is to decode a macro-instruction into one of a first plurality and a second plurality of micro-instructions. The multiplexing logic is to cause the macro-instruction to be decoded into the second plurality of micro-instructions instead of the first plurality of micro-instructions only when issued from the virtual machine.

Abstract: In one embodiment, the present invention includes a method for directly communicating between an accelerator and an instruction sequencer coupled thereto, where the accelerator is a heterogeneous resource with respect to the instruction sequencer. An interface may be used to provide the communication between these resources. Via such a communication mechanism a user-level application may directly communicate with the accelerator without operating system support. Further, the instruction sequencer and the accelerator may perform operations in parallel. Other embodiments are described and claimed.

Abstract: In an embodiment, a method is provided. The method includes managing user-level threads on a first instruction sequencer in response to executing user-level instructions on a second instruction sequencer that is under control of an application level program. A first user-level thread is run on the second instruction sequencer and contains one or more user level instructions. A first user level instruction has at least 1) a field that makes reference to one or more instruction sequencers or 2) implicitly references with a pointer to code that specifically addresses one or more instruction sequencers when the code is executed.

Abstract: In one embodiment, an apparatus includes a calculation logic to receive a plurality of wait certificates, each associated with a validated block of transactions of a distributed ledger system, and to generate a local mean value based thereon; a timer generation logic to generate a wait time for a proof of wait associated with a first block of transactions of the distributed ledger system based at least in part on the local mean value; a timer logic to identify when the wait period has expired; and a certificate generation logic to generate a wait certificate for the first block of transactions responsive to expiration of the wait period, the wait certificate to validate the first block of transactions. Other embodiments are described and claimed.

Abstract: In one embodiment, the present invention includes a method for directly communicating between an accelerator and an instruction sequencer coupled thereto, where the accelerator is a heterogeneous resource with respect to the instruction sequencer. An interface may be used to provide the communication between these resources. Via such a communication mechanism a user-level application may directly communicate with the accelerator without operating system support. Further, the instruction sequencer and the accelerator may perform operations in parallel. Other embodiments are described and claimed.

Abstract: A method and system to provide user-level multithreading are disclosed. The method according to the present techniques comprises receiving programming instructions to execute one or more shared resource threads (shreds) via an instruction set architecture (ISA). One or more instruction pointers are configured via the ISA; and the one or more shreds are executed simultaneously with a microprocessor, wherein the microprocessor includes multiple instruction sequencers.

Abstract: In an embodiment, a method is provided. The method includes managing user-level threads on a first instruction sequencer in response to executing user-level instructions on a second instruction sequencer that is under control of an application level program. A first user-level thread is run on the second instruction sequencer and contains one or more user level instructions. A first user level instruction has at least 1) a field that makes reference to one or more instruction sequencers or 2) implicitly references with a pointer to code that specifically addresses one or more instruction sequencers when the code is executed.

Abstract: A method and system to provide user-level multithreading are disclosed. The method according to the present techniques comprises receiving programming instructions to execute one or more shared resource threads (shreds) via an instruction set architecture (ISA). One or more instruction pointers are configured via the ISA; and the one or more shreds are executed simultaneously with a microprocessor, wherein the microprocessor includes multiple instruction sequencers.

Abstract: A system and method for BIOS flash attack protection and notification. A processor initialization module, including initialization firmware verification module may be configured to execute first in response to a power on and/or reset and to verify initialization firmware stored in non-volatile memory in a processor package. The initialization firmware is configured to verify the BIOS. If the verification of the initialization firmware and/or the BIOS fails, the system is configured to select at least one of a plurality of responses including, but not limited to, preventing the BIOS from executing, initiating recovery, reporting the verification failure, halting, shutting down and/or allowing the BIOS to execute and an operating system (OS) to boot in a limited functionality mode.

Abstract: In one embodiment, the present invention includes a memory management unit (MMU) having entries to store virtual address to physical address translations, where each entry includes a location indicator to indicate whether a memory location for the corresponding entry is present in a local or remote memory. In this way, a common virtual memory space can be shared between the two memories, which may be separated by one or more non-coherent links. Other embodiments are described and claimed.