KR20120099472A - Method and apparatus to provide secure application execution - Google Patents

Method and apparatus to provide secure application execution Download PDF

Info

Publication number
KR20120099472A
KR20120099472A KR1020127016450A KR20127016450A KR20120099472A KR 20120099472 A KR20120099472 A KR 20120099472A KR 1020127016450 A KR1020127016450 A KR 1020127016450A KR 20127016450 A KR20127016450 A KR 20127016450A KR 20120099472 A KR20120099472 A KR 20120099472A
Authority
KR
South Korea
Prior art keywords
enclave
processor
key
page
instruction
Prior art date
Application number
KR1020127016450A
Other languages
Korean (ko)
Other versions
KR101457355B1 (en
Inventor
존 가니
마이클 에이 골드스미스
개리 그라운케
길버트 네이저
데이비드 더햄
프라샨트 디완
카를로스 브이 로자스
디온 로저스
지앙타오 리
버나드 린트
프란시스 엑스 맥킨
도렌 스티븐 알 반
디케 돈 에이 반
어니 브릭켈
우데이 알 사바간카르
빈센트 알 스칼라타
어셔 알트만
스탈린셀바라즈 제야싱
사이먼 피 존슨
요셉 치훌라
스티븐 제이 토롭카
하워드 씨 허버트
Original Assignee
인텔 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 인텔 코포레이션 filed Critical 인텔 코포레이션
Priority to PCT/US2009/069212 priority Critical patent/WO2011078855A1/en
Publication of KR20120099472A publication Critical patent/KR20120099472A/en
Application granted granted Critical
Publication of KR101457355B1 publication Critical patent/KR101457355B1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10Address translation
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2105Dual mode as a secondary aspect

Abstract

Technology that enables secure application and data integrity within computer systems. In one embodiment, one or more secure enclaves are established in which applications and data can be stored and executed.

Description

METHOD AND APPARATUS TO PROVIDE SECURE APPLICATION EXECUTION}

Embodiments of the present invention generally relate to the field of information processing, and more particularly to the field of security in computer systems and microprocessors.

It is becoming increasingly important to secure the execution and integrity of applications and their data within computer systems. Some conventional security techniques do not provide sufficient security for applications and data in a flexible but reliable manner.

Embodiments of the invention are shown by way of example and not by way of limitation in the figures of the drawings in which like reference numerals refer to like elements.
1 shows a block diagram of a microprocessor in which at least one embodiment of the invention may be used.
2 shows a block diagram of a shared bus computer system in which at least one embodiment of the invention may be used.
3 shows a block diagram of a point-to-point interconnect computer system in which at least one embodiment of the invention may be used.
4 shows a block diagram of a multi-core microprocessor in which at least one embodiment of the invention may be used.
5 shows a possible implementation of a secure enclave (SE) in one embodiment of the invention.
6 shows a block diagram of a microprocessor in which at least one embodiment of the invention may be used.
7 shows an example of a control structure for accessing a portion of an enclave page cache that may be implemented in one embodiment of the invention.
8 shows an example of a thread control structure in one embodiment of the present invention showing how the data structures are stitched together.
Figure 9 illustrates one step of a software attestation process known as quoting, which may be found in one embodiment of the present invention.
10 illustrates steps for making a quart from a set of measurement resists in one embodiment of the invention.
11 illustrates an EADD process of updating the measurement register MR_EADD in one embodiment of the present invention.
12 illustrates EREPORT for generating a report in one embodiment of the present invention.
Figure 13 illustrates a response-protection mechanism found in one embodiment of the present invention.
14 shows an example of the MAC tree structure portion of the response-protection mechanism found in one embodiment of the present invention.
15 illustrates how a page fault error code map may be implemented in one embodiment of the invention.
16 shows an example of a process for creating a permit to launch an enclave in one embodiment of the present invention.
Figure 17 illustrates a possible implementation of the platform key hierarchy for a single package secure enclave for one embodiment of the present invention.
18 illustrates an example of a microcode based secure enclave key hierarchy in one embodiment of the present invention.
19 is a diagram of an enclave CTL_MSR register that may be found in one embodiment of the present invention.
20 illustrates a cryptographic blockchain algorithm used in one embodiment of the present invention.
21 is a flow diagram illustrating encryption of a single AES block in one embodiment of the present invention.
FIG. 22 is a flow diagram illustrating an example of encryption of multiple AES blocks using a cryptographic blockchain algorithm as implemented in one embodiment of the invention.
FIG. 23 illustrates an interrupt stack and application after an interrupt with a stack switch in one embodiment. FIG.
FIG. 24 illustrates a possible method for implementing a stack of multiple state save area slots in one embodiment of the present invention.
Figure 25 illustrates a portion of a state machine going through state transitions for interrupts, faults, and traps in one embodiment of the present invention.
26 shows a processor package for a digital random number generator for one embodiment of the present invention.
27 shows debug register DR7 2700 for one embodiment of the present invention.

Embodiments of the present invention relate to techniques for providing secure applications and data in a flexible but reliable manner. Although there are numerous embodiments of many aspects of the present invention, the document attached with the name "Secure Enclaves Architecture" is incorporated herein by reference as an example of at least one embodiment. However, the integrated reference is not intended to limit the scope of the embodiments of the invention in any way, and other embodiments within the spirit and scope of the invention may be used.

1 illustrates a microprocessor in which at least one embodiment of the invention may be used. In particular, FIG. 1 shows a microprocessor 100 having one or more processor cores 105 and 110, where each processor core is associated with a local cache 107 and 113, respectively. In FIG. 1, a shared cache memory 115 is shown that can store a version of at least some information stored in each of the local caches 107 and 113. In some embodiments, microprocessor 100 may also include other logic such as integrated memory controllers, integrated graphics controllers, not shown in FIG. 1, as well as other logic to perform other functions within a computer system, such as I / O control. Can be. In one embodiment, each microprocessor in a multi-processor system or each processor core in a multi-core processor includes logic 119 that enables a secure enclave technique in accordance with at least one embodiment. Or otherwise associated with it. The logic may include circuitry, software (embodied in a type of medium) that allows for more efficient resource allocation among a plurality of cores or processors than in some conventional implementations.

2 illustrates, for example, a front-side-bus (FSB) in which one embodiment of the present invention may be used. Any processor 201, 205, 210, or 215 is any local level one (L1) cache within or otherwise associated with one of the processor cores 223, 227, 233, 237, 243, 247, 253, 257. Information from the memories 220, 225, 230, 235, 240, 245, 250, 255 can be accessed. Moreover, any processor 201, 205, 210, or 215 may be configured to include system memory 260 via chipset 265 or information from any one of the shared level to L2 caches 203, 207, 213, and 217. Information can be accessed. One or more processors of FIG. 2 may include or be associated with logic 219 to enable secure enclave techniques, according to at least one embodiment.

In addition to the FSB computer system shown in FIG. 2, other system configurations, including point-to-point (P2P) interconnect systems and ring interconnect systems, may be used in conjunction with various embodiments of the present invention. For example, the P2P system of FIG. 3 may include several processors, only two of which are shown as examples. The processors 370 and 380 may include local memory controller hubs (MCHs) 372 and 382 for connecting with the memory 32 and 34, respectively. Processors 370 and 380 may exchange data over PtP interface 350 using point-to-point interface circuits 378 and 388. Processors 370 and 380 may exchange data with chipset 390 via separate PtP interfaces 352 and 354 using point-to-point interface circuits 376, 394, 386 and 398, respectively. Chipset 390 may also exchange data with high performance graphics circuitry 338 via high performance graphics interface 339. Embodiments of the present invention may be located in any processor running any number of processing cores, or in each of the PtP bus agents of FIG. In one embodiment, any processor core may include or be associated with a local cache memory (not shown). Moreover, a shared cache (not shown) may be included in either processor outside of the two processors or the p2p interconnect so that local cache information of one or two processors may be stored in the shared cache if the processor is in a low power mode. It may also be connected to the processors through. One or more processors or cores of FIG. 3 may include or be associated with logic 319 to enable secure enclave techniques, in accordance with at least one embodiment.

One or more aspects of at least one embodiment are implemented by representative data stored on a machine readable medium representing various logic within a processor that, when read by the machine, causes the machine to generate logic to perform the functions described herein. Can be. Such representations, known as "IP cores", may be stored in tangible machine readable media ("tape") and supplied to various manufacturing facilities or customers for loading into a manufacturing machine that actually manufactures the logic or processor.

Thus, a method and apparatus for micro-architecture memory region access have been described. It is to be understood that the foregoing description is intended to be illustrative, and not restrictive. It will be apparent to those skilled in the art that many other embodiments are possible by reading and understanding the above description. The scope of the invention, therefore, may be determined with the appended claims and the full scope of equivalents to which such claims are entitled.

A secure enclave is a set of instructions that provides a safe place for an application to execute code and store data internally in the context of an OS process. Applications running in this environment are called enclaves. The enclave runs from the Enclave Page Cache (EPC). The enclave page is loaded into the EPC by the OS. Whenever a page of an enclave is removed from an EPC, password protection is used to protect the trustworthiness of the enclave and to detect tampering when the enclave is loaded back into the EPC. Inside the EPC, it is protected using the access control mechanism provided by the enclave processor. Table 2-1 below provides a complete list of non privileged enclave instructions.

TABLE 2-1

Figure pct00001

These commands will also run only in ring 3. At all other times they will generate a #UD fault. Table 2-2 provides a list of privileged commands.

Table 2-2

Figure pct00002

Enclave Page Cache (EPC) is where enclave code executes and protected enclave data is accessed. The EPC is located within the platform's physical address space, but can only be accessed using SE instructions. The EPC may include pages from many different enclaves, but provides an access control mechanism to protect the integrity and reliability of the pages. The page cache maintains a coherency protocol similar to that used for the platform's coherent physical memory.

EPC can be instantiated in several ways. This may consist of dedicated SRAM on the processor package. Crypto Memory Aperture is known as a preferred implementation mechanism. This mechanism can make EPC large. A more detailed description of the CMA is described in the sections below.

The Enclave Page Cache Map (EPCM) contains state information associated with each page in the EPC. This state provides information such as the enclave to which the page belongs, the state of the loaded page, and so on. When a page is removed from the EPC, status information is also sent and protected using cryptographic means. When the enclave page is loaded back into the EPC, the status information is verified.

4 shows a block diagram of a multi-core microprocessor 499 in which at least one embodiment of the present invention may be used. Microprocessor 499 may include a number of cores 400, 420. One core 400 includes a CR3 402, an SMBR 404, a page-miss handler 408, a PMHE 410, and a translation index buffer 412. One core 420 includes a sms CR3 422, an SMBR 424, a page-miss handler 428, a PMHE 430, and a translation index buffer 432. Microprocessor 499 includes, in one embodiment of the present invention, a level-1 cache 440 shared between core 400 and core 420. Level-1 cache 440 may transfer data to and from the last level cache 445. The home agent 450 may be connected to the last level cache 445 and attached to the crypto engine 452. The home agent 450 may assert the physical address space 488 of the crypto memory aperture 480 through the memory controller 454. The cryptographic memory aperture 480 includes an enclave page cache 482, an enclave page cache map 484, and a backing store 486 as part of the physical address space 488.

CMA is a mechanism that provides support for instantiating EPC, EPCM, and other SE related structures. The aperture is a physical address space area that is reserved for this use.

EPC and EPCM (as well as other implementation data structures) are mapped to locations inside the aperture. Auxiliary storage is the actual data for these resources. When a memory request for an EPC is made, the CMA remaps and retrieves the data to an auxiliary storage location that contains encrypted EPC data.

In general, most SEs are implemented in microcode or extended microcode. There is hardware support required in several places, including logic to control data movement within the CMA, outside the package, and within the core.

5 illustrates a possible implementation of a secure enclave in one embodiment of the present invention. The operating system and the VMM 542 can load the enclave page in the enclave 532 into the enclave page cache 544 using the ELPG instruction 540. When the microprocessor is not running within enclave 532, enclave page cache 544 is protected from software access by SERR register 548. When executed inside an enclave, the microcode page table provides protection 546. Each VM has an associated VMCS. The VM 510 is connected to the VMCS 515. The VM 520 is connected to the VMCS 525. The VM 530 is connected to the VMCS 535. The SMM 500 can be in a separate container and the processor state can be in a separate container.

5 is a high level overview of one embodiment of a secure enclave implementation. In this embodiment, the EPC is maintained as an individual container managed by microcode. The container cannot be accessed when it is not running inside the enclave. Upon entering the enclave, control contained in the individual container is transferred to the enclave code inside the EPC.

Any page fault or exception that occurs while running inside an enclave is reflected by the microcode to the responsible OS or VMM. If the machine is not running inside the enclave, access control is provided to the EPC by the SE range register (SERR). When the machine is running internally, the microcode provides page table level protection that prevents access to other EPC entries that do not belong to the enclave being executed.

One option for implementing secure enclaves is to implement protection and instructions using microcode capability on some processors. This ability can meet the security requirements of the security enclosure itself to meet its objectives.

The SERR register as shown in FIG. 202 is implemented in a page miss handler (PMH). The registers can be enabled and disabled independently for each logic processor.

One option in an implementation to improve performance is to provide a bit or some bit to indicate an entry in an Translation Lookaside Buffer (TLB) for an enclave or a specific enclave. If these bits are not provided, a TLB flush will be required when leaving the enclave to prevent other code from accessing the enclave.

The enclave bit is compared to the enclave mode bit. The extra bits may provide the enclave space id function. An id may be assigned to a particular enclave. The id can be compared as part of the address check with the id of the running enclave. TLB support is an optional performance boost. The removal of EPC data requires a specific microcoded shutdown mechanism when entries can be invalidated in the TLB. In one embodiment, the microcode may connect with all other cores within the enclave trust boundary and verify that the entry no longer exists in any TLB. Other embodiments may provide a means for the microcode to ensure that another processor has invalidated the TLB entry.

Entries are provided to prevent DMA snoops and to invalidate certain SADs and / or TADs to the EPC. These dedicated registers provide protection of the EPC. This is set to the same value as SSERR.

To ensure a security key for each enclave, the secure enclave microcode may use secure access to random numbers in one embodiment.

The enclave may be protected against tampering. The details of the mechanism used for tampering protection vary by implementation. When the enclave is tampered, this will prevent further execution on the thread on which tampering was detected. To allow the user to understand the state of the enclave, there is an authentication mechanism implemented to provide proof of enclave construction. This includes the EREPORT command used to provide information to the enclave content.

To simplify the microcode code required in enclave design, the concept of structural enclave was developed. These enclaves have certain access privileges granted based on the original of the code for that enclave.

The enclave state during the power cycle depends on the software policy. Data inside the CMA is lost when the power is shut down. The software can ensure that enclave data is not lost during the power cycle if it wishes to maintain the enclave. Data residing in the EPC may be flushed into memory if the software wants to keep the enclave active across the S3 power state. The software can choose to require the application to disassemble all enclaves when power is removed.

Enclaves are protected differently depending on their location. Data outside the CPU package is protected using encryption and integrity checks. For code and data in the enclave page cache, the page is protected using an access control mechanism.

6 shows a block diagram of a microprocessor in which at least one embodiment of the invention may be used. 6 shows a microprocessor 600 having a number of processor cores 600, 605, 610, 615 and cache 620. Enclave data 635 may be protected. Encrypted memory aperture data 630 is used to protect enclave data 635.

Enclave pages residing in system memory are protected using encryption and integrity. While loading a page into the EPC, the page is copied into the EPC, decrypted, and the integrity of the page is checked. 6 illustrates this portion of data.

When an enclave page residing inside the EPC is stored in system memory, it is encrypted with an enclave key. In addition to storing the page, authentication information is also stored. Enclave data inside the EPC is decrypted and protected by an access control mechanism. The processor protects this data so that only the enclave that owns the data can access it.

When an enclave page residing in the EPC is evicted from the cache into main memory outside the CPU package, it is protected by CMA encryption. CMA will provide data reliability by encrypting data. The integrity of the EPC is provided by a range register that prevents reading and writing to the EPC.

7 shows an example of a control structure for accessing a portion of an enclave page cache that may be implemented in one embodiment of the invention. Each page of enclave page cache 720 may have metadata corresponding to enclave page cache map 710. 7, and the secure enclave containing the set of linear addresses 700, when the linear address matches a linear address stored in the enclave page cache map 710, 720). ≪ / RTI >

7 shows the layout and use of EPC and EPCM. EPC is divided into 4k pages. Each enclave may have several of the pages residing in the EPC. There is an entry in the EPCM for each page of the EPC that provides the meta information needed to ensure security. Details of the EPCM are specific embodiments.

When an application wants to load an enclave, it will call system routines within the OS. The OS will attempt to allocate some pages to the EPC. If there is no open spot, the OS will select and remove the victim enclave. The OS will retire the victim enclave's page using the EWBINVPG instruction for each page. When the OS completes the eviction, it will use the ECREATE command to add a secure enclaves control structure (SECS) to the enclave. After the SECS is generated, the OS will add the page to the enclave using the EADDPRE instruction as requested by the application.

To add a data page to the enclave, the OS may preferentially add a SMAP page to the enclave using the EADDSMAP instruction. Depending on the size and layout of the enclave, the OS will add some SMAP pages. Once all enclave pages have been added to the enclave, the OS will execute the EINIT instruction that causes the enclave to run. The parameter to the EINIT instruction is a permit that allows the enclave to be allowed to run on that machine. When an application is loaded, a permit needs to be created. After EINIT completes successfully, the application can execute the EENTER instruction to enter the enclave.

Once the enclave is built and marked for execution, the application may need to add or remove physical memory inside the enclave. To support this, there is an instruction that can cause additional memory to be added to the enclave. To add memory to the enclave, the memory is allocated to the correct linear address inside the enclave. The OS copies this memory page into an EPC representing a linear address. The EADDPOST instruction is executed to add this memory to the enclave. If the SMAP node does not reside inside the EPC, it may be loaded first.

After the memory is copied, the enclave software can accept the page before it can be accessed internally. The enclave accepts data by executing the EACCEPT instruction. This instruction can only be executed by software inside the enclave.

In some cases, software may want to modify the characteristics of the enclave memory. To make the change, the SMAP can be updated. For example, software may want to create another thread entry point, a TCS inside an enclave. In this case, the enclave requires the OS to change the SMAP characteristics of the page using the EMODIFY instruction. After the property is changed, the enclave software executes the EACCEPT instruction to make the page available.

Memory pages may be removed from the enclave. When the enclave is ready to remove the page, it sends a request to the OS. The OS will execute the EREMOVE command to remove the page from SMAP. The EREMOVE instruction also invalidates the EPC entry.

To ensure the integrity of the enclave environment, multiple access checks can be made. Among the various security features, it is enforced that the reference address is not broken to ensure that the data is correctly located in the EPC and that the code does not travel to a different linear address within the enclave to prevent data from leaking between enclaves.

Access protection requests can be implemented using range registers and microcode management shadow page tables. In another embodiment, page miss handler hardware may be modified to execute the same access control request to avoid the overhead of the new page table.

The EPC may access the LP if the logical processor (LP) runs in microcode extended mode, or if the linear address that LP runs inside and is accessed within the enclave falls within the linear address range covered by that enclave. . In other words, only microcode extended access or enclave access is allowed to go into the EPC range. Any other access to the EPC range is considered illegal.

Enclave access may be resolved with a physical address belonging to the EPC. If the access deviates outside the EPC but the linear address indicates an address inside the enclave, the access may be suspended. The fault for the OS or command is reported.

Access to addresses in the enclave can be located inside the EPC for continued access. Checking that an entry exists in the EPC is generally done by checking the EPCM to verify valid bits. Each EPC page is assigned a specific enclave. Note that an EPC entry can only be made by the enclave that owns the EPC page. This is checked by validating that the referenced page matches the SECS of the running enclave.

Each EPC page represents a specific linear address page for the enclave. The requested linear address may match the linear address of the page in the EPC. For example, an EPCM entry stores a linear address where the enclave page has brought into the EPC. When the enclave access resolves to an EPC page, the linear address from which the page came in may match the linear address of the current request.

The linear address mapping of the enclave cannot be compromised. If the page table of the linear address is corrupted, the resulting access is illegal. This prevents an attacker from moving code and data around inside the enclave.

If a page is added to an enclave after the OS / VMM has been initialized, the EADDPOST instruction sets the "pending" bit in the EPCM for that page. The pending bit survives following subsequent EPC wipe-back and eviction (using SEC_INFO). The enclave may issue EACCEPT to clear the pending bit. If the enclave access resolves to an EPC page with the pending bit set, the LP issues an EF_PENDING fault to the OS / VMM.

When the OS / VMM loads a response protection enclave page into the EPC, it sets the Freshness Check Required (FCR) bit in the EPCM entry for that page. The OS / VMM can clear this bit by executing an EUPSMAP instruction on that EPC page to clear this bit. Enclave access is allowed to continue accessing only if the FCR bit on that page is not set. Otherwise, the LP forwards the EF_FRESH_CHK fault to the OS / VMM.

Each EPCM entry contains a "dirty" bit indicating whether the enclave is allowed to write to that page. The enclave is allowed to write to that enclave page if the dirty bit for the enclave page in the EPCM is set. If not, the LP issues EF_EWRITE to the OS / VMM. The OS / VMM can set the dirty bit by executing an EUPSMAP instruction on that page.

Whenever a logical processor runs inside an enclave, the SECS page of that enclave may be provided to the EPC. However, the SE security model requires that the enclave may not be allowed to make any direct memory access to its own SECS (otherwise the enclave would completely compromising its own enclave). Key will be read). When an enclave access resolves to its EPC page, which reserves SECS for that enclave, it is notified to the OS / VMM via the EF_ATTRIB_SECS fault. Enclaves are not allowed to modify any page with the TCS attribute set. If the enclave attempts to modify the TCS loaded into the EPC, the OS / VMM is notified via the EF_ATTRIB_TCS fault.

In the size fields of the following table, the following values and indicators are used:

4 4-byte fields in 32-bit and 64-bit mode

8-byte fields in 32-bit and 64-bit mode

8 (4) 8 byte field on both sides. The upper 4 bytes are ignored in 32-bit mode.

Note: Some fields have names (eg oLSP) starting at the lower case "0". These fields are pointers, but are indicated in the enclave as an offset to the base of the enclave. This representation ensures that the measurement of the enclave page is independent of where the enclave is generated.

Note: The fields are not (yet) described in any particular order. Some fields may, for example, be moved to different memory pages in their respective data structures to enable different protection means.

Table 4-1

Figure pct00003

Thread Control Structure (TCS) is associated with each thread. The TCS includes the Table 4-2 TCS layout.

Thread control structure

Table 4-2

Figure pct00004

The thread state can have one of five values:

Figure pct00005

State storage offset (oSSA)

State storage area offset refers to the stack of state storage frames used to store the processor state upon interruption or exception occurring during execution in the enclave. Next State Save Area (NSSA) is used by the interrupt microcode to determine where to store the processor state at interrupt or exception occurring during execution in the enclave. This is the index into the array of frames addressed by oSSA. The Count of Save Area (CSSA) specifies the number of SSA frames available for this TCS. When an interrupt or exception occurs and no longer an SSA frame is available (NSSA> = CSSA), the interrupt or exception will still occur and the processor state will be cleared, but the TCS will be marked as INVALID.

For interrupts occurring during execution in an enclave, the machine state will be stored in TCS :: SSA (State Save Area). This area is shown in Table 4-3. Contains an interrupt storage area.

Figure pct00006

TCS :: SSA cannot be paged out at the time the interrupt occurs. EENTER checks that the SSA is inside the EPC and caches the physical address. If the page is retired, the processor running EWBINVPG uses the SSA to force the enclave exit on the processor currently executing the thread and report a page fault to it.

8 shows how all the data structures are merged together. To avoid clutter, no per-thread structure is shown for all threads. Unreliable stacks and their associated pointers are also omitted. 8 shows an example of a thread control structure showing how storage state regions are merged together in one embodiment of the invention. The state storage area pointer 800 points to storage area 0 820. Current state storage area 805 points to storage area 1 824. State storage area 810 then points to storage area 828. The number of storage state areas provides a reference to the number of storage state areas available.

Page information (PAGE_INFO) is a structured data structure used as a parameter for an EPC-management instruction.

Table 4-3

Figure pct00007

The SEC_INFO flag and the EPC flag contain bits indicating the type of page.

Figure pct00008

The SEC_INFO flag is a set of bits describing the state of an enclave page.

Table 4-4

Figure pct00009

The security information (SEC_INFO) data structure holds cryptographic meta-data necessary for anti-counterfeiting.

Table 4-5

Figure pct00010

A certificate (CERT) is a certificate structure provided in a structural enclave and sent to EMKPERMIT. This structure is 4096 bytes long and can be page aligned.

Table 4-6

Figure pct00011

PERMIT was output from EMKPERMIT and Permit Enclave and was consumed by EINIT. This is 4096 bytes and can be page aligned.

Figure pct00012

The ERPORT structure is the output of the EREPORT command.

Table 4-7

Figure pct00013

MEASUREMENTS is an output parameter of the ERDMR command. This includes the measurement register values of the enclave, taken from the particular SECS.

Table 4-8

Figure pct00014

The key request (KEY_REQUEST) is an input parameter for the EGETKEY command. This is used to select the appropriate key and any additional parameters required for derivation of that key.

Table 4-9

Figure pct00015

Table 4-10

Figure pct00016

Table 4-11

Figure pct00017

This structure is used by key derivation to generate a key based on the enclave and the secure version of the SE TCB of the enclave. See Platform TCB Recovery Sepecification for more details on the TCB security version structure.

Table 4-12

Figure pct00018

Table 4-13

Figure pct00019

Table 4-14

Figure pct00020

Table 4-15

Figure pct00021

The EPCM flag is a set of bits describing the state of an enclave page.

Table 4-16

Figure pct00022

The Enclave Page Cache Map (EPCM) is a security structure used by the processor to track the contents of the page cache. The EPCM holds exactly one entry for each page currently loaded into the EPC.

Table 4-17

Figure pct00023

Attestation is a process that indicates that a piece of software has been established on a platform, especially as a remote entity. In the case of a secure enclave, this is the mechanism by which the remote platform establishes that the software is running on a protected authentication platform within the enclave before trusting the software with the secret and protected data. The verification process has three phases: measurement, storage and reporting.

There are two measurement periods within the enclave pre-enclave setup and the post-enclave setup. It is the role of the enclave instruction to provide the measurement of the enclave as set. If the enclave has been set up, the software inside the enclave is responsible for the measurement.

9 illustrates one step of a software verification process known as quorum, which may be found in one embodiment of the present invention. In one embodiment, the signature operation 910 applies the signature key 915 to the connection data from the measurement registers 901, 902, 903, 904. The result of the signature operation 910 is a quote 920.

The reporting operation cryptographically combines the measurements made when the enclave is created with the platform. As this type of functionality is often available as a TPM command on the platform, this mechanism is often referred to as quota. The value of the measurement register MR is concatenated and then signed using the asymmetric key. Any challenger must simply verify the signature of the quote structure to validate the quote.

10 illustrates, in one embodiment of the present invention, the generation of a quart from a set of measurement registers 1000. The local report 1005 may be generated by accessing the measurement register 1000 with an asymmetric authentication key. Quoting enclave 1025 may include software that converts local report 1005 to anonymous quote 1010 or normal quote 1020.

Due to the nature of the calculations related to our hope for reducing the number of instructions in the asymmetric key and enclave leaf, we will not include instructions that sign asymmetrically. Our approach, shown in the following figures, is to provide a hardware-based mechanism for generating a 'report' based on a symmetric key authentication key, where these asymmetric key-based 'reports' are software that is protected using an enclave. Can be converted to asymmetrically signed 'quoting'. As the quoted enclave needs to be authenticated to access the platform verification key, the quoted enclave itself is a special purpose enclave known as the authentication enclave.

Each enclave provides two 256-bit wide measurement registers (MR_EADD & MR_POLICY) and two spare registers. These measurement registers are contained within the SECS of the enclave.

11 shows an EADD process for updating the measurement register MR_EADD 1100 in one embodiment of the present invention. The expansion operation 1115 may take as input the current values of MR_EADD 1100, page data 1105, and page metadata 1110. The output of the extension operation is MR_EADD '1120, which is the next value to store in MR_EADD 1100.

MR_EADD contains the total measurement of the enclave as it is built using the EADD instruction before the EINIT instruction is called. It is only written by the microcode and therefore needs to be placed on the page of the SECS which is only read by the enclave code. In each call of EADD, the page data and the security metadata associated with that page, i.e., the relative address of the page (w.r.t. for the base address of the enclave) and the SEC_INFO. Compute SHA256 over the flag, and this value is extended to MR_EADD 1100. Here we define 'extension' as meaning:

New MR Value = Hash (Old MR Value? Input Value)

MR_POLICY contains the value of the policy used to authenticate the policy that authorized the enclave to be launched. This value can be taken from the enclave permit that was placed in SECS at launch and copied as successful completion of the EINIT instruction. MR_POLICY is only written by the microcode, so it needs to be located in the page of the SECS which is only read by the enclave code.

12 illustrates an EREPORT for generating a report in one embodiment of the present invention. KEYID 1200, owner epoch 1205, package fuse key 1210, and fixed string MAC key 1215 are possible inputs to derivation command 1220. The derivation 1220 output of dlm, along with the current values of the TCB version 1232, ISV version 1234, capability 1236, flag 1238, user data 1240, and measurement register 1242, is determined by the CMAC 1125. Can be entered. The output of the CMAC 1225 may be stored in the MAC 1244. The output of the EREPORT command includes key identification 1230, TCB version 1232, ISV version 1234, capabilities 1236, flags 1238, user data 1240, measurement registers 1242, and MAC 1244. It may include.

The EREPORT instruction generates an intermediate key for performing symmetric key based GMAC across measurement context, user data, and additional contextual information such as enclave's capabilities and flags.

In addition to the measurement registers, the user can also provide a 256 bit wide block of data for inclusion in the report. There are many specific values that the user would like to prove, such as challenger NONCE and / or application generated keys. These values are reduced to a single hash and submitted to the report for inclusion.

To prevent key consumption by repeatedly calling EREPORT, a random 128 bit value (known as reportKeyID) is generated on each power cycle of the processor and stored in an internal location. This value is incremented after a 2 ^ 32 AES operation using this value. Each call to the EREPORT instruction will, in one embodiment, increment this value by one.

Table 5-2

Figure pct00024

The flag field in the report structure can be used to determine any state information about the enclave, or when the EREPORT instruction is called which will be useful for the challenger to state whether they can trust the enclave.

Table 5-3

Figure pct00025

In one embodiment, the architecture enables a structural enclave with the appropriate capability settings to retrieve the key used for the EGETKEY command and CMAC operation, thus verifying that the report has been generated on the currently running hardware. This capability is limited for the Quoting Structural Enclave.

In order to retrieve the measurement of the enclave when executed outside the enclave, an ERDMR Read Measurement) instruction is provided. This instruction takes a pointer to a valid SECS page and a pointer to the address to which the measurement is to be delivered. The measurement is delivered in the form of a MEASUREMENT structure. The MEASRUEMENT structure is not encrypted and protected.

Table 5-5

Figure pct00026

Enclave pages are cryptographically protected when they are not inside the enclave page cache. There are three levels of password protection: reliability protection, anti-counterfeiting, and response protection. In one embodiment, the application is allowed to select a protection level for each enclave page independently of the protection level selected for other pages of the same enclave. Implementation of Enclaves MAY allows an application to choose between the following combinations: anti-counterfeiting, anti-counterfeiting and response protection, reliability and anti-counterfeiting, and reliability, anti-counterfeiting, and response protection. Trust and anti-counterfeiting on the enclave page can be achieved using one of several authenticated cipher modes, such as Galois Counter Mode (GCM) in combination with appropriate ciphers such as AES. However, response protection requires a more complex solution.

Figure 13 illustrates the mechanism of anti-counterfeiting and response protection found in one embodiment of the present invention. Anti-counterfeiting prevents an attacker from substituting different values of encrypted data that are not generated by the program. Response protection prevents an attacker from replacing a value of encrypted data that is not the current final value generated by the program. The node version number 1300 may enter the IV 1310 and then the GMAC 1325 algorithm. The version number for the child 1305 may send data 1315 to the GMAC 1325 algorithm. The GMAC 1325 algorithm combines the keys 1320, IV 1310 and data 1315 to generate the MAC 1330.

Response protection ensures that all content of an enclave belongs to a single snapshot of a non-corrupted enclave as seen by the logic processor at any given time. Thus, the response protection mechanism needs to define the concept of an enclave version and provide a mechanism to determine whether an anti-counterfeiting enclave page belongs to that enclave's version. To this end, the response protection mechanism associates the content of each forged anti-enclave page with the page version number using a message authentication algorithm such as GMAC. In the case of GMAC, the version can be used as part of the initialization vector IV as shown in FIG.

Figure 14 shows an example of the MAC tree structure portion of the response protection mechanism found in one embodiment of the present invention. Leaf node 1425 may include version information for an individual MAC content page 1430. Each leaf node, such as 1420, includes a separate MAC content page (not shown). Each internal node 1410, 1415 may include version information of a child to which it is linked. The root 1400 is the top level node in the tree data structure.

To extend the version to the entire enclave, the response protection mechanism maintains the version tree. The leaf node contains a version of the individual response protection page of the enclave instance. Each internal node provides a version of each child group, thus logically holding the version information for the page they represent. 14 illustrates this concept as a picture.

In one embodiment, the tree structure was chosen to reduce the number of data needed to process O (log n) in O (n) pages. The use of version trees instead of hash trees was chosen to enable page eviction from EPC without tree updates.

Because response protection can require each page to have its own version that is cryptographically linked to its content, response protection requires anti-counterfeiting. Therefore, anti-counterfeiting in the SE architecture is essential. In addition, the initial implementation of the SE may further restrict the list of supported protection combinations.

OS / VMM creates an enclave by executing the ECREATE instruction. During the creation of the enclave, the range of linear addresses protected by the enclave is specified. This linear address range is known as an Enclave Linear Space (ELS) range.

Once the enclave is created, individual pages belonging to the ELS range are added to the enclave using the EADDPRE instruction. The EADDPRE instruction brings each added page to the enclave protection domain by moving these pages into the enclave page cache. If any of these pages outside of EPC use EWBINVPG, the logic processor will take cryptographic protection on those pages.

Encryption protection is achieved by associating cryptographic meta-data with each enclave page. This meta-data is used by the uCode flow for various processor instructions to decrypt the contents of the enclave page and verify the authenticity / freshness of each enclave page. The SE architecture provides several such instructions for updating, managing and validating cryptographic meta-data.

Each enclave page has a security information SEC_INFO data structure associated with it. The purpose of the SEC_INFO data structure is to hold cryptographic meta-data required to decrypt and verify the page. The various fields of the SEC_INFO structure are as follows:

[Table 6-1]

Figure pct00027

The security information flags (SEC_INFO.Flags) describe the page type, encryption for protected pages, and access protection.

[Table 6-2]

Figure pct00028

A security map (SMAP) is a data structure used to store cryptographic meta-data required to verify the freshness (ie, response protection) of an enclave page. The security map represents the full version tree for a specific snapshot of the enclave. Each node of the protection map holds a version for 256 child nodes (or enclave pages in the case of leaf nodes). Additional meta-data about the secure node is included in SEC_INFO for the particular SMAP node.

In one embodiment, the security map tree is at two levels of depth (the depth of the security map relates to the size of the enclave supported by the SE architecture. In general, the SE architecture will support a maximum enclave size of 32 GB), It is accessed using the enclave offset of the enclave page within that enclave. The root of the SMAP is contained in the SECS and it only holds versions for 128 child nodes. Bits from the enclave offset are used to select the appropriate children used to index the SMAP. In general, the enclave offset is 35 bits long. The enclave offset is extracted by the following formula (enclave linear address & enclave mask). The enclave mask is determined by (size of enclave-1) and can be calculated during ECREATE.

Table 6-3

Figure pct00029

In general, at depth l > 1, bits N− (l) × 8 to N− (l + 1) × 8 + 1 are used to select the appropriate child at the next level.

Note : Security maps are logical data structures, not structural ones. The logic processor does not even know where the SAMP is located in the linear address space. System software is responsible for maintaining and walking the security map. Each individual node of the security map has a structurally defined structure-however, the architecture does not specify how the security map is maintained in memory. However, note that each node in the security map has a well-defined logical location in the security map, and once the node is moved around in the map, the various processor instructions associated with the security map will interpret it as an attack scenario.

The root secure node is included in the SECS and contains version information for 128 children. A non-root secure node is a protected page and its associated SEC_INFO. The protected page contains version information for 256 children.

Table 6-4

Figure pct00030

SEC_INFO contains the location of the SMAP within the SMPA. The location with SMAP is determined by the linear / enclave offset and page type SMAP_LEVEL_1 and SMAP_LEVEL_2.

Adding a response protection enclave page requires that the FCR bit be cleared while the SMAP parent has been created and resides inside the EPC. To verify the integrity of the enclave page, the logic processor generates a key using IV_P and key_id in the SEC_INFO structure. The key is used to compute the MAC across the flag and the content of the page in the SEC_INFO structure. The computed MAC is compared with the MAC located in the SEC_INFO structure. If the MAC matches, the page is considered to have passed the integrity check.

The logic processor verifies the integrity of the page as it is loaded into the EPC using ELPG instructions. As part of this instruction, the logic processor downloads the IV-P from the SEC_INFO structure used to verify the page.

To verify the freshness of the enclave page, the logic processor verifies that the enclave page and its smap parent have been loaded into the EPC and that smap parent is fresh. Next, proceed to check the version of the page against the version stored in the smap parent. If the two versions match, the processor creates a new version for that page and updates the version of the smap parent and the version of the enclave page. Finally, mark the enclave page as fresh.

Annotation-Creating a new version makes the page modifiable. This both simplified the architecture and implementation.

To remove the enclave page, the logical processor verifies that the enclave page and its smap parent are loaded into the EPC and both are fresh. Next, proceed to set the version of the page in the smap parent to 0 and mark the EPC slot of the enclave page available.

The Enclave Perspective Cache (EPC) is a secure storage used by the CPU to temporarily store an Enclave page if the Enclave page is not cryptographically protected by SE encryption protection.

The following requirements are identified on the EPC. Access to an enclave memory page loaded into an EPC belonging to a non-debug enclave may be protected from any modification by software entities outside that enclave. An attacker cannot read plain text data belonging to a non-debug enclave loaded into an EPC by a direct hardware attack. An attacker cannot modify data in an EPC belonging to a non-debug enclave by a direct hardware attack. Any data loaded into the EPC may be coherent and securely accessible from the CPU in the system.

There are several mechanisms for implementing EPC. The EPC may be implemented as on-die SRAM or eDRAM. EPC may also be configured by dynamic isolation of the CPU's last-level cache. In such implementations, the EPC may be protected from unauthorized access from outside the package. However, other packages in the system can coherently and securely access the EPC.

Another mechanism for implementing EPC is Crypto Memory Aperture (CMA). CMA provides a cost effective mechanism for creating password-protected volatile storage using platform DREAM. CMA uses one or more globally located cryptographic units on a CPU uncore to provide varying levels of protection depending on the needs of customer technology. Various uncore agents are modified to recognize memory accesses going to the CMA and route them 25 to cryptographic controllers located in the uncore. Depending on the desired level of protection, the cryptographic controller creates one or more memory accesses to the platform DRAM to fetch cipher-text. Next, create plain text and process the encrypted text to satisfy the original CMA memory request. CMA is fully integrated into Intel's QuickPath Interconnect (QPI) protocol and scaled to a multi-package platform with security extensions to the QPI protocol. In a multi-package platform 30 configuration, the CMA uses link-level security (Link-Sec) at the externally facing QPI link layer to protect memory transitions between Intel CPUs.

SECS is said to be active if currently loaded into the EPC. As will be described later in this document, the OS / VMM is responsible for managing what is being loaded into the EPC. However, while loading an enclave page into the EPC, the OS / VMM needs to tell the CPU the whereabouts of the SECS for that page, except when the page under consideration becomes the SECS. If the page being loaded is not a SECS, the CPU requires that the SECS corresponding to that page be located in the EPC. Before loading any page for an enclave, OS / VMM MAY loads the SECS into the EPC for that enclave.

The CPU does not enforce any limit on how many times the SECS should be loaded into the EPC-however, it is not quite common for the OS / VMM to load multiple copies of the SECS into the enclave page cache. Nevertheless, even if multiple copies of the same SECS are loaded into the EPC, each of those copies is considered as a separate active SECS instance, and the enclave pages loaded into the EPC belonging to different instances of the active SECS are in different enclaves by hardware. It is considered to belong.

OS / VMM sees EPC as a contiguous block of physical memory in the system address space. However, to reduce internal storage, and to enable fast indexing, the CPU associates a slot identifier (SID) with each EPC page. The physical address of the EPC page and the corresponding slot identifier are associated with each other as follows.

sid = (page_pa-epc_base_pa) >> 12

page_pa = pc_base_p | <sid << 12)

The hardware uses the specific slot identifier 0xFF to define the invalid slot. The EPC slot identifier is used by both uCode and PMH to track information about the enclave page.

Every enclave page loaded into the EPC has a well defined system physical address. Since there is a one-to-one mapping between physical addresses belonging to the EPC and EPC slot identifiers, we say that each page loaded into the EPC has its own EPC slot identifier or EPC_SID.

Additionally, all enclave pages are associated with an active SECS instance, except for SECS pages, which are loaded into the EPC. Recall that an active SECS instance is nothing more than a SECS page loaded into an EPC. As a result, the active SECS page also has its own EPC_SID. The EPC_SID of the SECS page to which the non-SECS enclave page belongs is referred to as the SECS_SID for the non-SECS 25 page. For each page loaded into the EPC, the hardware maintains SECS_SID. The SECS_SID for the SECS page loaded into the EPC is defined as 0xFF, or an invalid SID.

EPCM is a security structure used by the processor to track the contents of the page cache. 30 The EPCM holds exactly one entry for each page currently loaded into the EPC. For the page represented by it, each EPCM entry tracks such information as the enclave to which the page belongs, the linear address the page entered into the enclave page cache, the version of the page, and so forth. The EPCM structure is used by the CPU in the address translation flow to enforce access control on enclave pages loaded into the EPC. EPCM entries are managed by (x) uCode as part of various instruction flows.

In one embodiment of the invention, the enclave page cache (EPC) may be dynamically allocated or deallocated. In one embodiment, software such as an operating system may dynamically allocate pages to memory as EPCs or deallocate memory from EPCs. In one embodiment, the operating system may assign any page to an enclave that will be in the EPC. The EPC may occupy all available locations in memory in some embodiments. According to one embodiment, one distinction of dynamic EPC from fixed EPC is that dynamic EPC enables the addition and removal of pages of memory. In one embodiment, logic such as a software driver may allocate a memory area that resides in the EPC, and may deallocate memory from the EPC. In one embodiment, the pre-boot process checks the available memory to store metadata for each page of memory, and the software can declare the page to be in an EPC or non-EPC, but hardware Logic can track and enforce the attributes of each page.

In one embodiment, the hardware logic may control access to the memory to be used as the EPC through a translation lookaside buffer (TLB) and a page miss handler (PMH). In one embodiment, when the search address matches in a TLB known as a TLB hit, the TLB may be flushed when the secure enclave exits the EPC. In one embodiment, when the search address does not match in a TLB known as a TLB miss, an extra lookup may pull data from the enclave page cache map (EPCM) for multiple memory references. In one embodiment, the PMH may perform a lookup of the EPCM. In another embodiment, the range register of the PMH is checked to control access to consecutive physical addresses, EPCs. The operating system does not allow direct memory access (DMA) to access the EPC page. If the returned page of memory is marked as an enclave page, the secure enclave control structure identification (SECSID) of the page can be checked for that of the currently executing enclave to ensure that the access is secure. If there is a mismatch between the SECSID of the returned page and that of the currently running enclave, the PMH may issue an abort message. If the returned page in memory is not marked as an enclave page, or if the returned page in memory is marked as an enclave page and the SECSID of that page matches that of the running enclave, the PMH will load the page translation into the TLB. Can be. In one embodiment, cache tags may be used to identify enclave lines from other lines for rewrite cycles. However, in at least one embodiment, the cache tag is not used if the logic that determines the type of memory request accesses the EPCM during the rewrite cycle.

In one embodiment of the invention, the software, BIOS may allocate memory prior to booting the operating system to generate an enclave page. The software may, in one embodiment, generate an EPC with a sequence of steps in the BIOS. The BIOS may store some metadata and reserve some memory for each processor to set range registers. The BIOS can take as input the base address and the memory size. System configuration is checked by a process known as MCHECK to ensure that all packages and all cores are correctly set up to provide protection from access outside the enclave. MCHECK will lock the register until the system is reset. In another embodiment, the software may add the page to the EPC by an instruction known as EPCADD that declares that the portion of memory is part of the EPC. The EPCADD sequence can take a memory address as input and output a message indicating success or failure. In the case of EPCADD outputting a message indicating success, EPCADD may set the EPCM.E bit and the page corresponding to that physical address is flushed from all TLBs in the system. In one embodiment of the invention, EPCADD may return with an error code of RAX of 01 indicating that the page with the input address is already an EPC page, and with an error code of 02 indicating that the input address is out of range. . Pages of memory declared by EPCADD as part of EPC may require EPC semantics to access data. In this embodiment of the present invention, the software can remove the page from the ePC in an instruction known as EWBINVPG and allow the encrypted data to continue to be used while protected by encryption and integrity protection. Data in this format can be stored on regular memory of the hard disk drive. In another embodiment, the software may, in an instruction known as EPCREMOVE, remove pages in the EPC and make encrypted data unavailable. The hardware executing EPCREMOVE clears the page and parts of the EPCM. EPCREMOVE can be run without first running EWBINVPG. The EPCREMOVE sequence, in one embodiment, removes a page from the EPC based on the memory address. In an embodiment of the present invention, the EPCREMOVE instruction is an error code of RAX of 01 indicating that the page being removed is part of a secure enclave control structure (SECS) and can be removed, and the 02 of 02 indicating that the page being removed is not an EPC page. It may contain an error code. The global TLB shutdown of a page of memory may be derived from EPCREMOVE in one embodiment of the invention, and the memory previously occupied by the page becomes available for general software access.

PMH prevents access to the protected area of the memory space. Depending on the architecture, this may simply be a physical address check of access to the EPC. Additional PMH support can be used to enable performance improvements or alternative implementations of the SE. The SE architecture relies on a page-miss handler (PMH) to prevent unauthorized access to enclave pages loaded into the enclave page cache. PMH detects various events and reports those events back to microcode. The microcode can report events to the OS / VMM. OS / VMM can then remedy the fault by executing the appropriate command:

When an enclave is created using the ECREATE instruction, a linear address range is specified for that enclave. This range is called the linear address range for that enclave. Any memory page that falls within the enclave's linear address range is considered to be under the protection of the enclave and has an SEC_INFO entry associated with it.

Memory pages that belong to the linear address range of an enclave are also referred to as enclave pages . Programs running inside an enclave are allowed to access the enclave as long as those pages are loaded into the enclave page cache and that is the enclave that owns the page. The processor will generate an exception-class event if this is not the case. The OS / VMM is responsible for ensuring that the enclave pages are loaded into the EPC as needed.

If a logic processor is executing an enclave and creates a memory access to its enclave page, such memory access is referred to as enclave access . The address can be checked to ensure that it is accessed by the correct entity.

In one embodiment, the PMH provides access control to protect the EPC when the program is not running in the enclave. An enable range register for each logic processor will restrict access to the EPC when the processor is not executing enclave code. This range register is disabled when a process begins executing enclave code. There, the processor puts a particular page table in place. These page tables allow only access to EPC pages controlled by the processor and owned by the enclave. The processor and microcode use these two mechanisms to restrict access to the EPC.

In some embodiments, a tradeoff may be made during many axial axes including performance, spherical complexity, and silicon cost. Three possible implementations are described in this chapter to help developers understand some of the possible tradeoffs. Table 8-1 below shows these possible protections and required PMH support.

Table 8-1

Figure pct00031

As shown in the first row of Table 8-1, one additional range register is all that is required to provide the necessary access control protection. In this particular embodiment, other protection is provided by the microcode extension. The range register may be enabled based on the logic processor. A basic implementation using this mechanism is shown in Figures 2-2.

The PMH is modified to prune out access from the LP to the CMA range (covered by CMRR in the CPU) that is not executed in extended microcode or in enclave mode. In addition, LPs running in enclave mode are only allowed to access the EPC subranges of the CMA.

15 illustrates how a page fault error code map may be implemented in one embodiment of the invention. When bit 5 1540 is set, bit 9, bit 8, bit 7 and bit 6 are decoded together to determine the page fault error code. res bit 1512, I / D bit 1514, RSVD bit 1516, U / S bit 1518, W / R bit 1520, and P bit 1522.

When a page is not provided to the EPC, a fault is provided to the OS / VMM to indicate this fact. The page fault error code map is changed as shown in Table 8-2. This represents a new bit used to report a faulting condition. If there is no EPC fault, bit 5 is set to zero and bits 6 to 9 are also set to zero. If the fault is due to an EPC condition, bit 5 will be set and the software can decode bits 6-9f to understand the EPC fault condition. More information about fault types is described in the next section.

When bit 5 of the page fault error code is set, bits 6 through 9 are interpreted as given in Table 8-2. This shows the condition under which the page fault occurs. Some states represent illegal conditions that can never occur in normal operation. They indicate OS / VMM management errors.

Table 8-2

Figure pct00032

To protect the EPC from attack, there may be a mechanism to invalidate the EPC address in every TLB on the platform. This feature can signal all cores that a particular page will be invalidated. Next, you can wait until all processors return an indication that the shutdown is complete.

Each time an enclave exit, EEXIT occurs, the TLB may not allow access to the enclave pages currently present in the TLB. This can be done by clearing the TLB or using extra bits to tag the enclave entry.

One alternative uses an enclave bit in the TLB on an enclave exit where all enclave entries are cleared. Another alternative uses several bits to identify a particular enclave. In this case, the enclave entry does not need to be evicted. The enclave entry may remain in tlb. When the address is sent to tlb for lookup, these bits are appended to the lookup. These bits are compared to enclave ids from the core representing the enclave identity. If the bits match, the request comes from the same enclave. If the match fails, the request did not come from the particular enclave and the lookup would not hit at that location.

Enclave authentication provides a means for determining the copyright licensed enclave code to execute within an enclave that is the author / certifier of the code. Enclave authentication also provides the foundation to outsource enclave microcode flow, Flexible Sealing & Reporting, as well as enforcement points for many new business models.

Certain aspects of secure enclave architectures are complex and require a time consuming flow, which is not suitable for implementation within microcoded instructions. The solution is to outsource part of the secure enclave architecture to macrocode. In many cases, outsourced code requires special access to sensitive processor or platform data. For example, the EPID signature is too long for a single instruction. Instead, a Quoting Enclave is used to create EPID signed quotes by granting special access to the EPID private key. Enclave authentication allows Intel to specify additional capabilities that are permitted for a particular enclave, such as access to an EPID key only by a quoted enclave. Enclaves provided by Intel that have additional capabilities and implement core enclave functionality are referred to as structural enclaves.

Enclave Sealed Storage provides enclave software with the ability to encrypt data for any attribute of an enclave, such as a load time measurement. The enclave verification framework may allow the enclave to provide external agencies with evidence of the measurement of the enclave. In many circumstances, it is more desirable to seal or merge data into the source of the enclave rather than the precise software hash of the enclave.

In one embodiment, once the signature on the authenticated enclave is verified, the public portion of the key used to sign the enclave is made available to the Sealing & Attestation mechanism, and the rigid protection or code of the enclave based on the enclave measurement Vendors can choose between more flexible protection based on their source.

Enclave authentication is divided into two parts. Each enclave is accompanied by an enclave license as the signature chain is rooted back to Intel. An enclave license is who is the source / accountable entity for an enclave, any specific capabilities that the enclave requires, and any additional necessary to identify the specific business model / agreement that enabled this enclave. Represent information. The license may be for a particular enclave representing the measurement of the enclave, or may be for a key authorized to sign the enclave as needed.

For example, A purchases a license that authorizes them to create an enclave for using A's video player. To this end, Intel may generate a license for Vendor A's video player root key, along with the ability of Intel to allow Vendor A to use in the video player enclave. Vendor A will use a video player root key to sign a separate license file for each video player revision they distribute. This creates a license chain for an enclave that can contain multiple intermediate licenses.

The chain of signed licenses is not ideal for evaluation during the enclave launch process, so instead they are combined into a structure that can digest a single instruction called permit. Permits are symmetrically authenticated using the CMAC algorithm and are interpreted during the initialization of the enclave (EINIT).

Table 11-1

Figure pct00033

Table 11-2

Figure pct00034

Most of the components of the license are copied into permits to create a similar structure. LicenseID identifies a business agreement as a 64-bit number. LicenseType identifies the platform to which this license applies. The bulk license allows this enclave to be started on platforms that support secure enclaves. The per platform license requires that the platform first contact the indicated License Authority and asks for authorization to start the enclave. Given authorization, no further contact with the license entitlement is required, but this allows the entitlement to track the number of platforms on which this enclave is deployed for billing purposes. The ISV that licensed this enclave may choose to set a secure version number for this version of the enclave. By doing so, the data sealed by this version may be made available to later versions, but not earlier versions. The Flags field indicates the flags for the enclave that this authorization can be set for to apply. Capabilities mask is a bit mask of special capabilities that can be given to this enclave. ParentKeyHash signs the enclave's license and is a hash of the public key, hashed with the public key that signs the key. EntityHash is the expected hash of the entity to which this license applies. For enclaves, this is the value of MR.EADD for the properly generated enclave. For licensing keys, this is a hash of the public key.

In the license, the public key used to sign the license is contained in the license itself. Permit is MACed using a CPU key. The appropriate cpuMAC indicates that the EMKPERMIT instruction generated this permit after validating the license chain back to Intel. If LicenseType is not bulk, licenseMAC indicates that the structured license enclave has connected the appropriate license entitlement and that the platform has been confirmed that it can start the enclave.

Not all enclaves require a permit. To facilitate the development of the enclave, the permit may be optional during the development and debugging phase of the software. The following policies can be enforced by EINIT. Non-debug enclaves always request a permit to be started. The debug enclave will start without a permit. However, if no permit is specified in the EINIT, then the MR.Policy, IVS Sec Version, Permit Sec Version, and Capabilities will all be set to zero.

If a permit is used to start a debug enclave, permit-> Flags [DEBUG] can be set, and only the capabilities allowed by the debug enclave can be set in the permit.

16 shows an example of a process for creating a permit to initiate an enclave in one embodiment of the present invention. The process can have three steps. That is, a permit issue 1600, an additional license permit 1640, and an initialization enclave 1680. In the permit issuing step 1600, the ISV key permit 1615 can be generated by executing the EMKPERMIT instruction 1612 for the ISV key license 1610. Enclave permit 1625 with MAC for CPU only can be generated by executing EKPERMIT instruction 1612 for ISV key permit 1615 and enclave license 1620. In an additional license permit step 1640, the enclave permit 1625 with MAC only for the CPU and the third party enclave corresponding to the information to be licensed enter the license enclave 1644, and the license enclave 1644 ) Generates an enclave permit 1645 with a MAC for the CPU and the license. In initialization enclave step 1680, enclave permit 1645 with enclave SECS 1802 and MAC for CPU and license may be input to EINIT 1684. The output of the EINIT 1684 command is an ISV enclave 1685.

To start an enclave, a permit may be generated from a license included with the software and provided to the CPU to start the enclave. This process is divided into three. That is, issuance of permits, additional license permits, and enclave initializations. Reference shows the flow through this process.

The new command EMKPERMIT is used to generate a permit from the license. EMKPERMIT generates a single permit from a single license, but can be called in succession to convert the chain of licenses to a single permit with a MAC using the permission key. The next section will explain this process in more detail.

Each license includes a license type, which determines the additional steps in which the permit can be executed to make it available. The license per platform may require that the license entitlement in the cloud maintains the billing number of the platform on which the enclave is deployed. For this type of license, additional steps are required. A structural enclave, called a license enclave, will negotiate with license entitlements in the cloud and, if there is a permit, use a license key to provide additional MAC for the permit. For example, an architectural enclave is always a bulk license, which means that it does not require a license key MAC for execution. They run on any platform that supports secure enclaves.

In enclave initialization, a permit is executed. During initialization, the permit is processed, and if the enclave measurement matches that in the permit, and the MAC is correct, the enclave begins. EINIT will look at the license type and will only check the license MAC for licenses that require additional permits.

EMKPERMIT is a privileged command because of the time required to permit RSA signature for a license. This command is a very simple signed credential that attaches to the uCode patch format, commits it, and generates a permit from its contents. The license includes both the public part of the key and the signature used to sign it. This only allows uCode to store a hash of the license signing key and validates the Intel signed license. EMKPERMIT may also validate licenses signed by these keys to provide authorized permissions of the ISV keys. This is accomplished by generating a permit containing a hash of the ISV public key. As a result, the Intel license can be authorized using an internal hash or an ISV key with a hash provided by the second permit.

EMKPERMIT takes three parameters, including a pointer to a license, an optional pointer to a key permit, and a pointer to an output permit. For Intel-signed licenses, the key permit is null and an internal hardcoded set of permit parameters is used. The calling method is used to validate the license of the structural enclave and generate a permit for it. EMKPERMIT allows you to verify the public key in the license by uCode (by comparing the hash of the embedded public key with the internal hash).

In the case of an ISV, the ISV's key will have a license signed by Intel. By calling EMKPERMIT without a key permit, you will use Intel key hash to verify the signature on the license, and generate a permit that authenticates the hash of the ISV key to represent a legitimate license signing key. EMKPERMIT is called a second time, containing the permit of the ISV's key. EMKPERMIT validates the MAC of the key permit and uses the hash of the ISV key that previously used the Intel hash. Assuming that the public key in the enclave license is hashed with the value of the ISV key, and the enclave license is properly signed by it, EMKPERMIT will generate a permit for the enclave. This permit displays license information (which may be consistent throughout the entire chain), a hash of all public keys in the license chain, the measurement of the enclave, and its capabilities.

During EMKPERMIT, the next step is executed by u-code.

1. Copy the parameters to the scratch pad (protection against race condition attack).

2. Calculate the hash of the public key in the license.

3. If key permit == NULL,

a. Verify that License Public Key Hash = Intel Key Hash or Fail.

4. Otherwise,

a. Use the permit key to verify the MAC of the key permit.

b. Verify that the license public key hash = EntityHash of the key permit or fail.

5. Verify the signature of the certificate with PubKey.

6. Verify that License Info, Capabilities, and Flags are consistent between the license and the key permit.

7. Create a permit with:

a. PubKeyHash = Hash (KeyPermit.Hash, Hash (License PubKey))

b. Capabilities = KeyPermit.Capabilities & License.Capabilities

c. Measurement = License.Measurement

d. ISV SVN = License SVN

e. Flags = License Flags

KeyID = current KeyID in the core

9. cpuMAC = CMAC calculated using Permit Key

10. licenseMAC = 0x0000.. 0000

The license enclave is designed to make decisions about enclaves that start outside the scope of visibility for uCode. For example, uCode cannot evaluate whether an ISV's business agreement with Intel allows for further enclave deployments. The license enclave is designed to collect all the materials needed to evaluate, permit or reject enclave initiation. License enclaves are only required to support complex business agreements and are not required for bulk licenses such as the ability to initiate enclaves on as many platforms as needed.

The license enclave is expected to be a system service. If the license indicates that additional entitlement was required from the license enclave, the enclave permit and chain of licenses generated by EMKPERMIT are passed to the license enclave. The license enclave generates a permit request. The application sends this permit request to the appropriate license entitlement, which generates a permit notification. This is passed back to the license enclave, which uses the license key to MAC the permit in the licenseMAC field.

Once a permit is issued for an enclave, it can be evaluated and executed by u-code in the enclave start process. This is done as part of the EINIT command, which takes the linear address of the permit as a parameter. The next additional step is added to EINIT as part of the Authorized Enclave mechanism.

1. Copy the permit to the scratch pad.

2. Use the permit key to verify cpuMAC against the permit.

3. If LicenseType! = Bulk, verify the licenseMAC using the license key.

4. Compare the measurement at the permit with MR.EADD in SECS.

5. Compare the Flags in the Permit to the flags in the SECS.

6. Copy the Pubkey Hash in the permit into MR.Policy.

7. Copy ISV SVN to SECS.

8. Copy the Capability Map in Permit to SECS.

Capabilities

The current capability map is a 128 bit mask of the capabilities available for this enclave.

Table 11-3

Figure pct00035

The space is organized based on the action to be taken by the EINIT. Bits 00-03, ring level restrictions are reserved for future use as they are activated in this enclave. 04-07 is reserved to indicate which page protection is allowed in the future. 08-23 are processor keys available through EGETKEY. 24-31 are for other controls, such as using a name based mode for verification, or for future technology to be limited. Certain capabilities may not be used at all by the enclave in debug mode. The Debug column indicates whether the capability will be used legally in debug mode.

In future generations, bit 00 may indicate that ring level and VT restrictions apply to this enclave. Bit 01-02 indicates the ring level at which the enclave is allowed to run and bit 02 indicates whether the enclave is running in VT root mode. In each EENTER, the current CPL can be compared against bits 01-02, which determines if this enclave is allowed to run at this ring level. If you try to run on the wrong ring, EENTER will fail. Similarly, if ring restriction is enabled, when bit 03 is on, the enclave will only enter from VT root mode. In the first generation, these bits are MBZ.

Enclave pages can be encrypted or only complete protection. In addition, the page may or may not be executed. In future generations, these attributes are tracked and can be executed in the security information portion of the EPCM. These capabilities are reserved to control the application of encryption to enclave a page in an enclave based on whether the page is executable and whether the enclave has already been EINIT.

Many architectural enclaves are Ring 3 entities that require access to keys protected in or by the CPU. The EGETKEY provides access to these keys, while the capability bits are used by the EGETKEY to determine if access to the key can be allowed.

The following is a list of the current structural enclaves, including their attributes and a summary description.

Provisioning Enclave is certified by Intel with KEY_PROVISION capability and is available on a single package platform whenever a new Device Attestation Key (DAK) or Provisioning Attestation Key (PAK) is required. Is executed. This purpose is to allow the enclave to derive a Device ID & Provisioning Key based on the Providing Seed provided by the EGETKEY. The provisioning enclave uses these keys to prove the platform's authority to the provisioning server and retrieve the DAK. After retrieving the DAK, the serving clave seals it, allowing the quoted enclave to retrieve it. The serving enclave optionally uses the DAK to authenticate with the Platform Attestation Key (PAK) provider and retry the PAK. By using a PAK, for a particular ISV, the activity is not associated with that of the previous owner of the platform, thereby providing better privacy for the user. After retrieving the PAK, the serving enclave seals it so that the Quoting Enclave can retrieve it.

A quart enclave with the capability KEY_REPORT and authenticated by the enclave has the same author as the provisioning enclave (typically Intel) used to provide the EPID key. Its location is an OS service available to all apps. The purpose of this is to allow the enclave to unseal the platform EPID key. Reports from EPREPORT are provided as input. The enclave retrieves the report key using EGETKEY. The report key is then used to verify the report. The enclave signs the quotes using the EPID.

A license enclave licensed by Intel with the capability KEY_LICENCE and signed by the root Intel is instantiated and mounted solely on the OS Service. The purpose of this is to evaluate complex license policies. If the enclave requires additional license verification from the license enclave, EINIT will only accept it as a CMAC permit after the license enclave uses the license key.

In a single package system, all the symmetric keys used by the architecture of the enclave are derived from a unique single source stored in the fuse array of the processor. The key layer is divided into an SE TCB layer that depends on the platform implementation, and an SE key layer whose structure is related to all secure enclave implementations. The establishment of keying material and EPID provision for TCB recovery is provided by the SE TCB layer serving as the root for the SE key layer. All key material used in both the enclave instruction and in the structural enclave of trust is provided by the SE key hierarchy.

The platform provides two 128-bit unique keys for the fuses. These keys are encrypted in fuses using keys stored in secret CPU logic. Several single purpose keys are derived from this key, and TCB reconstruction techniques are applied based on platform requirements. The resulting key serves as the root in the SE key hierarchy.

The key for the structural enclave is retrieved using the EGETKEY instruction.

The enclave architecture also requires the use of asymmetric keys to provide verification of REPORT values for systems outside the platform. This key, the EPID key, is initially provided in the fuse, but can be provided again using one of the keys derived from the key hierarchy after deployment. The method of providing an EPID verification key is outside the scope of this specification. More information can be found in the Device Attestation Key (DAK) Provisioning Specification.

Finally, the enclave's architecture also uses keys in the logic of every processor to provide key material from the OEM. This key is known as the Out-of-Box Experience Global Key. We perform a similar derivation operation on this key to provide ISV uniqueness. How these keys derived from OOB keys are used by ISVs is outside the scope of this specification.

The SE TCB portion of the key hierarchy is platform specific, but all foundations require the same set of basic keys. We refer to them as base keys. They are both derived from fuse keys and logic keys and are the root of the SE key hierarchy. These keys are then used by SSE instructions to derive all the keys used directly in the SE architecture. These keys are the result of the TCB key hierarchy. There are four SE Base Key plus EPID components that are made available to the SE architecture by platform specific mechanisms. Table 12-1 describes each of these keys.

Table 12-1

Figure pct00036

17 illustrates a possible implementation of a platform for a single package secure enclave for an embodiment of the invention. Out of the box base key 1700 is derived 1702 from available derived resources 1750 to generate out of the box key 1704. Available derivation resources 1750 include fixed values 1756, owner epoch 1754, secure enclave secure version 1756, SECS measurement registers 1758, ISV secure version 1760, and SECS flag 1762. A string 1702 having an element to contain. The provisioning key 1710 may prove the platform's authentication to the Intel backend. EPID 1712 is a signature key. The initial safeID key blob 1718 is a quote and is associated with the safeID seed 1716. The base ops key 1714 is a series of keys including an enclave key 1730, a permit key 1732, a license key 1734, a report key 1736, an authentication key 1738, and a real key 1740. Information may be combined from the derived resources 1750 available to derive 1720.

17A illustrates one embodiment of a multipackage key hierarchy.

Secure enclave instructions and data structures rely on the base key as a source for keying material. The platform key hierarchy shown in Table 12-1 describes the hierarchical relationship of platform key material and how the key is derived from the platform root key.

Enclave wrapping key 1752 is a symmetric key used to encrypt a secure enclave control structure (SECS) page, but it is not protected inside the enclave page cache (EPC). This key is only used by uCode.

Permit key 1754 is used to provide authentication and integrity for the permit, including the capability and licensing information for the enclave. Permits are MAC to guarantee their integrity, but transition to EINIT. This key is used by EMKPERMIT uCode and EINIT.

License key 1756 is used to assert compliance with a license policy that cannot be evaluated by uCode. The license key is used to produce an authorized approval from the license enclave that is evaluated by EINIT. This key is used by EINIT uCode and is available via EGETKEY to enclaves with the KEY_LICENSE capability set.

The report key 1758 is used to provide authentication and integrity for the report. Reports are MACed by an ERPEPORT that transitions to the Quoting Enclave while ensuring their integrity. This key was used by the EREPORT uCode and is available via EGETKEY to enclaves with the QUOTE capability set.

The owner key 1760 is an enclave specific key and is used to provide authentication and integrity for data sent from the quoted enclave to the ISV enclave, enabling enclave to enclave authentication on the same platform. This key is available to all enclaves via EGETKEY, and an enclave with ISV_AUTH capability can specify which key to request.

The real key 1762 provides each enclave with a 128 bit key to encrypt their sensitive data. Multiple sealing policies can be incorporated into a real key, which ISVs provide flexibility for software to unseal their data. These keys are available to any enclave via EGETKEY, but individually the real key is only available to enclaves that satisfy the requested real policy.

EPID ID 1712 uniquely identifies the package. Its sole purpose is to enable the provision of device verification keys, which are EPID based anonymous verification keys. The EPID ID is only accessible to the serving enclave. The provisioning enclave will only provide this to the authorized provisioning server, over the secure channel, during the visioning process initiated by the user or computing system. This ID is available via EGETKEY to enclaves with PROVISIONING capability.

The provisioning key 1710 is used to verify the platform's authentication to the Intel backend and to authenticate the current SE TCB learning. By accepting access to the provisioning key, the provisioning server ensures that the enclave is in fact a device owned by the EPID ID and is running at least a particular TCB secure version. The provisioning key is unique to this package and the signer of the provided enclave requesting it. This creates a separation between serving infrastructures if more than one is used on a single platform. This key is available via EGETKEY to enclaves with the KEY_PROVISION capability.

The serving seal key provides the serving enclave with a 128-bit key to encrypt the offering in a way that can be retrieved even after the owner's change. This key is used to encrypt the old EPID to prove that the platform has not been called but has obtained a new EPID. The provisioning key is unique to this package and the signer of the provided enclave requesting it. This creates a separation between serving infrastructures if one D phase is used on a single platform. This key is available via EGETKEY to enclaves with the KEY_PROVISION capability.

The ISV Out of Box (OOB) Experience Key (1700) is a shared key between all Intel platforms and ISVs. This key is derived from the OOB Root unique to a particular ISV. The ISV can purchase access to this key, enabling them to encrypt the secret for this key and place it in the OEM's hard disk image. These secrets will only be accessible to their code running securely in a secure enclave and do not require the platform to go online or go through a complete key verification process. These keys are available via EGETKEY to enclaves with OOB capability.

The provided key is important for the secure enclave architecture but is not derived from the platform keying material. These keys are provided from a provisioning server or offline technology. The device verification key (DAK) is an anonymous signing key used to verify the characteristics of each enclave. This can be used by the ISV during key or secret provisioning to ensure that sensitive information is only sent to a protected instance of their untampered application.

There are two sources for device verification keys. The preferred architecture is to mount the initial DAK compressed in the fuse as an EPID key blob and EPID entropy. This allows the platform to execute the verification immediately after the first power on. The second source is to contact the DAK provisioning server, verify the legitimacy of the hardware using the EPID ID and the provisioning key, and download it. This second method is used not only by a fused EPID key but also by a platform that does not have any platform after we call the version of TCB of Haji. EPID fuses are accessible via EGETKEY to enclaves with PROVISIONING capability.

Platform Validation Key (PAK) provides an optional additional level of privacy. It can be associated with any use of the DAK. In particular, if an ISV enclave has name-based verification capability, a single ISV can determine if a given EPID modifies that service. (However, many ISVs cannot conspire to track users.) Because the DAK is platform specific rather than owner, this relationship continues through a waterfall event. Thus, some users will want to use their DAK to assert the legitimacy of their platform to a third party who will issue a PAK to use daily verification. In a multi-package platform, the DAK of each package is used to establish a PAK representing the entirety of the flat upon verification.

Key derivation for a user accessible key will be consistent with NIST Special Publication 800-108 (Recommendation for Key Derivation Using Pseudo Random Function). In constructing the key derivation function, a pseudo random function (PRF) is required. The PRF will be based on AES-CMAC as defined in NIST SP 800-38B, Recommendation for Block Cipher Mode of Operations-CMAC Mode for Authentication, May 2005, CMAC. (http: //csrc.nist.govv/publications/nistpubs/800-108/sp800-108.pdf). Key derivation generally looks like this:

Figure pct00037

The derived string consists of a subset of eight elements based on the specific key requested. Table 12-2 describes each available element that may be part of the derivation.

Table 12-2

Figure pct00038

Each key has a predetermined set of induction elements that will make up the induction string. Table 12-3 describes what elements are included in each key from the key hierarchy. Each row represents a key and the row indicates whether the key contains a specific element. A debug string is included if the SECS of the request enclave is in debug mode, and a "request" indicates that this element is not required, but selectable in the request to derive its key.

Table 12-3

Figure pct00039

Secure enclave support techniques for detaching and restoring software compromise at some point in the boot sequence. To support separation, all long term keying material provided to the enclave is derived using the secure version of the current TCB.

This section describes an example architecture in which the platform's resilient TCB consists of uCode, MCHECK, and microcode extensions (or uVMM) will be described. The hardware requirements are the same for any SE supported platform, but the exact key flow depends on the specific TCB element. Other platforms can be supported here using similar techniques that apply to them. For platforms that support Patch-at-Reset, this mechanism represents a Patch-at-Reset to enable full restoration of uCode, including separate upgrades between uCode revisions and proof of password.

The following keys are required in hardware to support CPU-based protection techniques. These keys are the basis of the TCB key hierarchy.

Stepping -Specific 256-Bit Logic Key : The 256-bit logic key is broken down into two parts-a 128-bit fuse wrapping key, and a 128-bit out-of-box experience key. However, it is possible to use a single 128-bit key for both adding more uCode.

Die -specific 544 bits of the fuse key : This includes a 32 bit group id, a 256 bit SafeId Ax value, and 256 bits of the pre-seed. The Ax value and 256-bit pre-seed are encrypted with the 128-bit fuse wrapping key described above.

Temporary Registers : Key-derived processes require keys that are stored and available only on vozlw and for uCode. Two 128-bit registers are required during the duration of the platform runtime. Additional 256 bit space is required for the EPID key until the CMA is up and running. After that, an additional 256 bits are no longer needed on the CPU.

TCB SVN register : This register is subdivided to hold the SVN for each TCB layer. The particular subdivision is at the discretion of the platform designer, but eight 8-bit SVNs may be desirable. Each session of this register may be uniquely lockable.

The combination of keys into a particular set of TCB versions is achieved by having uCode derive the first set of keys from the fused key based on the type of boot sequence to start (ie, a patch at reset or a later patch). After this, the fuse is locked and a chain of induction occurs at each node of the boot sequence.

After the low level code is loaded, the chain continues to contain an ISV-assigned secure version of the software running in the enclave. For any particular configuration, keys derived from the current version and keys from the previous configuration are accessible. This enables newer non-vulnerable seamless user data transitions.

Once a die-specific key is generated, it is encrypted with a key wrapping key. This not only increases the difficulty of extracting keys with hardware monitoring tools, but also provides protection for keys in transit before they are partially stacked.

The encryption algorithm used to encrypt these keys is 10 rounds of 128-bit AES-ECB decryption. The key generation server will apply an AES-ECB cipher to each key to generate a cipher text key that will be burned in the fuse.

Pseudorandom Functions (PRFs) used for derivation of keys in the TCB key hierarchy are platform specific. We recommend 128-bit AES-ECB for platforms that support AES-NI. The goal is to provide a non-reversible way to derive a key from another key. For this section, we use the following functional prototypes.

Figure pct00040

There are three methods used for key derivation for PRF. uCode Sets the relationship between the keys of different SVNs, while PRF Loop Derivation is used to put the SVN into the key. Especially,

Figure pct00041

This provides forward movement of the data. For example, let's run uCode SVN 3. The enclave uses EGETKEY to retrieve the seal key based on this version (PRFLoop (3)). UCode patch upgrade is passed in the field, and the next boot uCode SVN is 4. After the upgrade, the EGETKEY implementation will access the PRFLoop (4). When the enclave requests SVN 3 from EGETKEY , it can compute PRFLoop (3) = PRF PRFLoop (4) and thus retrieve the previous real key.

To establish this property, a loop of PRF is used, but because of the property that PRFLoop (x-1) is calculated from PRFLoop (x), we need to establish the maximum SVN and count again from it. Specific maxes will need to be established for each platform type based on the similarity of the patches and the required performance. We recommend 32 as the initial max point.

The application of PRF Loop derivation is generally as follows:

Figure pct00042

This method will be used to put the ucode's SVN into the SVN key that will be the subkey after the SE base key. The die-specific key in the fuse includes a 288 bit EPID value and a 256 bit random key. From these 256 bits, all non-ephemeral symmetric keys consisting of two 128 bit keys can be derived. Thus, techniques for deriving multiple keys from a single key can be generated. For this purpose, the fuse key is decrypted and we call it PRF using different fixed constants.

The application of key partitioning is generally as follows:

Figure pct00043

This technique is used to generate random numbers that are used as part of the EPID ID and as the provided ID.

If the SVN key is loop derived based on uCode SVN, it can be stored away from protected memory such as SE CMA. The extended microcode will use the MSR exposed to the extended microcode just to derive the key from the SVN key. The MSR takes a key selector indicating whether the basis for derivation is a global out off box key or a fuse key, and a set of requested SVNs for each TCB layer. This verifies whether the request is less than or equal to the current value. uCode applies any necessary PRF to retrieve the old SVN key, which is the requesting TCB SVN.

Figure pct00044

Figure pct00045

Figure pct00046

If an appropriate SVN key is available, this key is used as the key for the CMAC across the requested TCB SVN. The extended microcode then uses it as a SE Ops Seed for the Ops key (a value derived from a portion of the fuse key not known by Intel), or as a fixed string for the providing base key.

Figure pct00047

18 illustrates an example of a microcode based secure enclave key hierarchy in one embodiment of the present invention. In the reset microcode 1800 layer, the global wrapping logic key 1801 and the Intel-known unique root fuse 1802 are inputs to the unwrapping 1806 function. The output of unwrap 1806 and microcode SVN 1805 is input to PRF loop 1808. Microcode SVN 1805 and global root logic key 1803 are entered into another PRF loop 1809. The output of the PRF loop 1808 is stored in the SVN key 1810 register. The output of the PRF loop 1809 is stored in the global key register 1812. Microcode SVN 1805 is stored in register 1814. The global wrapping logic key 1801 and the SSE EPID A. x fuse 1893 are inputs to the unlab 1807 function and the result is stored in the SE EPID 1816 register. In the MCheck 1820 layer, the outputs of the MCheck SVN 1821 and TCB SVN register 1814 are stored in the TCB SVN register 1826. The SVN key register 1810 is stored in the microcode SVN register 1822. The global key register 1812 is stored in the global key register 1824. SE EPID 1816 is stored in SE EPID 1828. In the load microcode 1830 layer, the output of the microcode SVN 1831 and the TCB SVN register 1826 is stored in the TCB SVN register 1846. The microcode SVN register 1822 is stored in the microcode SVN register 1832. Global key register 1824 is stored in global key register 1834. SE EPID 1828 is stored in SE EPID 1838. At the XuMSR inference key 1840 layer, the microcode SVN difference 1841 is input to a PRF loop 1842 and a PRF loop 1844. The microcode SVN 1832 register sends data to the PRF loop 1842 and the global key register 1834 sends the data to the PRF loop 1844. The output of the PRF loop 1842 and the output of the TCB SVN register 1836 are input to the PRF loop 1846 and the output of the PRF loop 1844 and the output of the TCB SVN register 1836 are input to the PRF loop 1848 do. The output of the PRF loop 1846 is stored in the SVN base key 1850, and the output of the PRF loop 1848 is stored in the global key 1852. In the microcode 1860 layer, a unique root fuse 1894 unknown to Intel is stored in seed 1 1856, while the EPID group ID fuse is stored in EPID group 1858. Seed 1 1856 is input to PRF loop 1864 and PRF loop 1888. The output of the PRF loop 1888 is SE EPID seed1 1892. The output of the PRF loop 1886 is the SE ops seed 1890. SE ops seed 1890 coming from SVN base key 1850 and requested SVN 1864 are input to CMAC 1868 function to generate SE ops key 1872. The current SVN 1862 coming from the SVN base key 1850 is input to the CMAC 1866 function to generate the SE provided key 1870. When the SVN base key is equal to {0,0,0} (1874), the SVN base key 1850 is stored at seed 0 (1876). Seed 0 1876 is input to PRF loop 1878 and PRF loop 1880. The output of PRE loop 1878 is SE EPID ID 1882 and the output of PRF loop 1880 is SSE EPID seed0 1884.

All cores are synchronized and ensure that they are all in MCHECK using a doorbell or similar mechanism. If all cores are running MCHECK, the next step is taken by the BSP. The AP does not participate in the key flow:

1. uCode reads, decrypts, and locks fuses.

2. uCode applies the PRF loop to the SVN key and applies the PRF loop to the OOBE key that injects the uCode's SVN into both keys. uCode writes its SVN to the TCB SVN register and locks it.

3. MCHECK loader or early MCHECK code writes MCHECK's SVN into the TCB SVN register and locks it.

4. The microcode extension patch loader writes the microcode extension patch SVN to the TCB SVN register and locks it.

During extended microcode initialization or when calling EGETKEY, the extended microcode calculates the SE base key needed to satisfy the request. The base key can be cached in the CMA for future use for improved performance.

Table 12-4

Figure pct00048

To protect data across user privacy and platform waterfalls, a 256-bit random owner epoch is included in the derivation of the key. This value is generated randomly during ownership change. Prior to the use of the enclave key, the software may write the OwnerEpoch to SE_EPOCH_MSR. This can be accomplished by a BIOS that permanently stores in flash. This can be calculated from some user input, such as a hash of the user boot password. This may also be provided by the secure enclave driver before the enclave can be used.

The reliability of this value is required to ensure that data encrypted by the platform is encrypted by someone who owns the laptop after the waterfall. Compromising this value does not compromise any enclave data.

The SE Key Info structure is a non-persistent structure stored in a protected area of memory or a package. CMA is the most similar location, but it can be anywhere on die protected storage. During power on, SE Key Info is initialized. KeyID is set to a random value and the key count is set to zero. In each use of the enclave key, permit key, and report key, the KeyID is read and the key count is incremented. After using the 2 ^ 32 key, the KeyID is changed to the new random value and the key count is reset to zero. The SE Key Info layout is shown in 5.

Table 12-5

Figure pct00049

At power on, the platform key table is initialized by uCode. The BIOS or other host firmware requests the current owner epoch from permanent storage or from the user and writes it to LoadOwnerEpochMSR. At this point, the enclave key hierarchy is available.

Most enclave architectures rely on the use of keys to provide authentication and reliability of enclave data, and use architectural enclaves to process these keys for high level use to keep processor complexity to a minimum. For example, the Quoting Enclave uses the REPORT key to establish that the REPORT structure generated by the EREPORT instruction has been created on the platform, and the PERMITING Enclave consumes enclave PERMIT when the enclave is launching. Use the PERMIT key to generate

In addition to any application level, the enclave will need to access with a key to seal the secrets stored on the platform outside the enclave and will be unsealed when the application enclave is reestablished. .

The mechanism for doing this is the EGETKEY command. This is a single interface for establishing a secret about the current software environment.

EGETKEY currently provides access to the following keys:

PROVISIONING KEY ID-used by the structured provisioning enclave to identify a uniquely encrypted datablob (using PROVISIONING KEY) for the processor.

PROVISIONING KEY-Used by structured serving enclaves to decrypt data blobs that are uniquely encrypted to the processor.

PROVISIONING SEAL KEY-Used by the structured provisioning enclave to encrypt the EPID so that the enclave can decrypt the EPID even after the owner change.

PERMIT KEY-used by structural permitting enclaves to generate PERMITs.

REPORT KEY-Used by the structured Quoting Enclave to verify the REPORT structure.

ISV AUTH KEY-used by the Structured Quoting Enclave to generate authentication data for a specific target application enclave.

AUTH KEY-used by the application enclave to authenticate data sent there by the structured quota enclave.

SEAL KEY-used by the application enclave to encrypt data that it wishes to store outside of the enclave.

OOB EXPERIENCE KEY-used by ISVs for pre-provided encrypted data for out-of-box experience use (eg Blu-ray player).

Most of these values are raw in the processor, but in fact are derived from a single fuse key value by the request by the EGETKEY. They are derived by requiring that each of these keys is not a key to carry but is in a single key from a possible set. The particular key being delivered depends on a number of parameters, some of which are user selectable, others are based on a system or a specific state.

To select the key, the KeyRequest structure is used as input to the EGETKEY command. In addition to selecting keys, the user wants a KeyRequest structure that allows the caller to specify those variables under his control that he wishes to be used to generate the keys. The figure below specifies the KeyRequest structure:

Table 12-6

Figure pct00050

KeySelect is used to identify the key that the user requires, and KeyPolicy is used to establish what additional values are used to generate the key-a specific secure version of the structural enclave or a specific version of the application enclave, or (EGETKEY ENCLAVE Whether called from within) the measurement register associated with the current enclave.

Additional randomness can also be added to the key derivation, which is particularly required to prevent the exhaustion of keys and is used by the PERMITING and QUOTING structural enclaves. This can also be used by the application enclave when generating the SEALing key. Setting the field to zero indicates that no additional randomness will be added, otherwise the field points to 256 aligned data values. The figure below specifies the structure for the KeySelect field.

Table 12-7

Figure pct00051

KeyPolicy is a bit field selector and is used to determine which specific value from the user or system state will be used for key derivation.

Table 12-8

Figure pct00052

Enclave Registers and Controls

Table 14-1

Figure pct00053

Two enabling levels are provided for the enclave. The first enable is an opt in bit set by the BIOS. This is a write once function. This enables or disables the enclave capability until the next reset. The second enable is provided to the OS or VMM to dynamically turn on or off the enclave capability as needed.

19 is a diagram for an enclave CTL_MSR that may be found in one embodiment of the present invention. The least significant bit is Enable 1900. Bit 1 of the register is On 1910. Bits 2 through 63 are reserved.

Enclave capability is enabled by first setting the Enable bit in EnclaveCTL_MSR shown in FIG. This bit is the default to disable when a package reset occurs. This bit can be written once after a package reset.

The BIOS sets a bit to enable the enclave. If the BIOS clears the bit, the enclave cannot be enabled until that part is reset.

The software can detect support for the enclave by executing the CPUID instruction. The CPUID will return a result indicating whether the enclave is supported or not.

If the opt in bit is cleared, the CPUID reports that the enclave will not be executed.

The system software controls the enclave capability using EnclaveCTL_MSR shown in FIG. The On bit allows the software to dynamically control access to the enclave capabilities.

The software detects support for the enclave by executing the CPUID instruction. Enclave support is indicated if the ON bit in the EnclaveCTL MSR is set.

The TCSMSR register is a register on each processor that contains the address of the TCS. This is used by exception handling and RDTCSPTR. This is loaded when entering the enclave. The register is loaded with the value of TCS when EENTER is executed. This is read by ERDTCSPTR. The register size is based on the mode of the processor.

The enclave base address register on each processor contains the lower address of the running enclave. It is loaded when entering the enclave by microcode. The register size is based on the mode of the processor. This register is not visible to software. This is a microcode temporary.

The register holds the upper address limit of the current enclave. This is loaded when entering the enclave. The register is loaded with the value stored in the SECS when the enclave starts executing. This is a microcode temporal register. The register size is based on the mode of the processor.

The Enclave Page Cache (EPC) Maximum Size register indicates the maximum size of the EPC. This size is given by the number of 4096 byte pages. This is a 32-bit register. This register is read only to indicate the maximum size EPC supported by the current design.

EPC Size Register EPC_SIZE The MSR indicates the currently defined size of the EPC. Loading a register results in a defined EPC by size. The value is given in 4096 pages. For example, one 4096 bit page may be one. The value of the register cannot exceed the value of EPC_MAX. If the value exceeds the EPC_MAX value, a GP fault is taken by the WRMSR instruction. Writing to this register will invalidate all data in the EPC before writing. The software can save all EPC entries (if needed) before updating this register.

The EPC base register indicates the position of the base of the EPC. Writing to this register will invalidate all data in the EPC before writing. The software can save all EPC entries (if needed) before updating this register.

In general, the external interface is not capable of any transfer or transaction that can compromise the security of the enclave. The secure enclave requires a random number for the enclave key. Random bits are generated using a digital random number generator. The random number generator may be securely accessible by microcode. It does not need to be located in the partial core.

Figure 26 shows a processor package for a digital random number generator, for one embodiment of the present invention. The processor package 2600 may include a plurality of cores, that is, core 0 2640 and core 1 2670. Core 0 2640 may include an external instruction microcode 2602, an internal function microcode 2644, an internal function microcode 2646, an RNG microcode module 2650, and an RNG queue 2654. Core1 2670 may include an external instruction microcode 2672, an internal function microcode 2674, an internal function microcode 2676, an RNG microcode module 2680, and an RNG queue 2684. Read random instructions 2630 may communicate with external instruction microcode 2262, while read random instructions 2635 may communicate with external microcode 2672. Process package 2600 may also include DRNG 2602 taking STD 2608, OPE 2610, PSK 2612 and TSC 2614. DRNG 2602 may include a digital entropy source 2604 that is connected to online self test 2606. The output of the online self test 2606 may be one input of a combined conditioner / deterministic random bit generator (DRBG) 2620.

The enclave can be set as a debug enclave when created. The debug enclave will enable external access to enclave content using the EDBGRD and EDBGWR instructions. Debug enclaves are set up by setting debug flags on the ECREATE instruction. This bit is stored inside the SECS of the enclave.

The enclave produced by the debug bit clear is a production enclave. The EPC contains a debug bit indicating that the enclave is a debug enclosure. A debugger that needs to check the enclave content will load the memory into the EPC. The EDBGRD and EDBGWR instructions can be used to access enclave memory locations residing in the EPC. Debug enclaves do not require a permit to run. This will run without valid permits.

When entering the production enclave, debug control register DR7 is stored in the TCS storage area. DR7 is shown in FIG. 27. 27 shows debug register DR7 2700 for one embodiment of the present invention. Register DR7 2700 includes bits L0 2702, L1 2706, L2 2710, L3 2714, G0 2704, G1 2708, G2 2712 and G3 2716. The other bits in the DR7 register 2700 are LE 2718, GE 2720, 001 (2722), GD 2724, 00 (2726), R / W0 (2728), LEN0 (2730), R / W1 ( 2732), LEN1 2734, R / W2 2736, LEN2 2738, R / W3 2740 and LEN3 2742.

Bits L3-L0 and G3-G0 are set to zero values. DR7 returns to its original value at the enclave exit.

For debug enclaves, the debug register value is not changed. When RFLAGS.TF is set at the start of the EENTER command, two cases are considered:

The debugger is either legacy (non SE-aware) or the enclave is in production (non-debug) mode.

SE-aware debuggers target debug-mode enclaves.

In the first case, #DB exception may occur for the target of the next EEXIT command. This handles the enclave as a massive opague operation. In the second case, the user freely completes in a single step via the enclave. This behavior is supported by the special processing of REFLAGS.TF, EEXIT and EIRET on 3 data fields and EENTER in the enclave.

Table 15-1

Figure pct00054

Table 15-2

Figure pct00055

The register value is stored in the TCS storage area. The register is set to zero. At the enclave exit, the register is stored back to the value at the entry. If the enclave has branch traces enabled in the entry, EENTER is the last entry before enclave entry. When exiting the enclave, the first position after the exit is recorded in the branch trace.

Int n and Int 3 instructions are reported as GP faults if executed inside the enclave. The debugger can hook GP fault conditions when debugging the enclave.

In this document, we describe a new technique for implementing the CMAC mode of operation for AES block ciphers. CMAC is a mode that supports message authentication. Accepts message A and key K as input and returns an authentication tag T. Derivation of the authentication tag is done using a cipher block chaining (CBC) algorithm. CMAC is more complicated than CBC because it includes mechanisms for protection against lengthening attacks. We refer to these as the 'three characteristics of CMAC'. In the following, we provide an overview of the CBC and CMAC.

20 illustrates a cryptographic block chaining algorithm used in one embodiment of the present invention. The initialization vector 2000 and the stage-1 input 2010 are input to the exclusive or gate 2012. The output of exclusive or gate 2012 is input to a stage-one block cipher 2015. Next, stage-1 block cryptographic output 2018 is input to stage-2 exclusive or gate 2022 along with stage-2 input 2020. The output of exclusive or gate 2022 is input to stage-2 block cipher 2025. Next, the stage-2 block cipher output 2028 is input to the next stage (not shown) of the cipher block chain.

The CBC algorithm uses block ciphers to provide trust for some pieces of data or to compute authentication tags for this data. The main idea behind the CBC algorithm is that the output from the previous cipher is XORed with the next input block before it is encrypted. In this way, patterns that can be exited from input data are removed from the ciphertext. In addition, the combination of XOR operations between the exchanges of block ciphers provides a powerful mixing that leads to an ideally unmodifiable message authentication tag.

The CBC algorithm is given below and shown in FIG. 20. The cipher is assumed to be a 128-bit block cipher in the case of AEA.

Figure pct00056

The CMAC details include three additional algorithms to initialize and terminate the CBC algorithm. We refer to these as the "three characteristics" of the CMAC. The first characteristic relates to the derivation of two subkey values K 1 and K 2 from the symmetric key K. Subkeys K 1 and K 2 are derived from the median L. CMAC explains that L is derived by applying a symmetric key block cryptographic transformation on a string consisting of zeros (ie 0 128 ) using a symmetric key value k . Such a relationship is shown in equation (1).

[Equation 1]

Figure pct00057

If L is derived, the most significant bit of L is checked. If this is zero, K1 is derived from L by shifting left by one bit position. Otherwise, L is shifted left by one bit position and also XORed with a specific value R b to produce K 1 . R b is defined as <0 120 10000111> in binary form. K 2 is generated from K 1 after the same procedure.

The derivation of subkeys K 1 and K 2 is given by the pseudo-code below. With MSB () we mean the most significant bit value.

Figure pct00058

A second characteristic of the CMAC relates to padding that occurs before applying the CBC algorithm to the input data. If the last block of data is not a complete block, the block is padded with one bit equal to " 1 " followed by as many zeros as needed to complete the final block.

The third characteristic of the CMC relates to modifications to the final block that occur to avoid lengthening attacks. If the last block is complete (no padding required), the last block is XORed with subkey K 1 . Otherwise, it is XORed with the subkey K 2 .

The algorithms for creating and validating CMAC tags are listed below.

Figure pct00059

Figure pct00060

Figure pct00061

In the following, we show how the symmetric key block cipher used can implement the CBC () algorithm when the AES Jade processor supports a set of instructions for AES round acceleration. The Intel architecture supports four new such instructions in the time frame of the Westmere processor (2009). These instructions are AES round encryption (AESENC), AES last round encryption (AESENCLAST), AES round decryption (AESDEC) and AES last round decryption (AESDECLAST). Details about these commands follow.

Table 16-1

Figure pct00062

In order to implement CMAC mode using the AES round instruction, it is enough to call AESENC AESENCLAST because the tag validation process is the same as tag generation. 21 shows a flow chart associated with encryption of one AES block. 22 shows a flow chart associated with encrypting multiple AES blocks using the CBC algorithm.

To implement key schedule conversion, you can use AESIMC for the inverse mix column, and the AESKEYGENASSIST command AESKEYGENASSIST is used to generate the round key used for encryption. AESIMC is used to convert an encryption round key into a form usable for decryption according to an equivalent inverse encryption model. A description of the AESIMC and AESKEYGENASSIST commands is given at http://softwarecommunity.intel.com/articles/eng;3788.htm.

CMAC is specified using a big endian notation of the amount of 128 bits involved. In order to correctly implement CMACmf in a small endian machine, it is necessary to perform a 16 byte-wide byte reflection operation at any point in the source code implementation. Such operation can be performed quickly using the PSHUFB instruction (one clock latency, throughput). Next, we describe the points at which byte shuffling is required.

In the SUBKEYS () algorithm implementation, byte reflection is required for L after derivation by applying AES to the zero string and before derivation of the two subkeys. Byte reflection is also required for the two subkeys after they are derived from L. The SUBKEYS () implementation is given below in C.

Figure pct00063

Figure pct00064

Next, byte reflection is required for the last block before and after padding if this last block is not complete. These steps are shown below as C.

Figure pct00065

Figure pct00066

Here, the function _pshufb () performs 128-bit wide byte reflection.

SE Requirements for SMI

Enclaves are not allowed to run inside the SMM space. Attempts to execute an enclave in SMM mode result in a GP fault of the instruction. If an SMI occurs during execution inside the enclave, the processor can save and exit the register state inside the enclave. If an exit occurs, the TBD MSR bit is set to indicate that SMI occurred while the enclave was running. The SMM code cannot access the enclave. An attempt to touch the EPC area will result in the return of junk data in real mode and an EPC page fault in protected mode.

Any command is not allowed to be executed. There are a number of general rules used to determine which instructions are legal.

1. Ring level changes are not allowed inside the enclave. Commands that can change or change the ring level are prohibited.

2. External software cannot service VMEXITS inside the enclave. Any instruction that can or can generate VMEXIT inside an enclave is prohibited.

3. The software cannot create a virtual machine inside the enclave. All VMX instructions are prohibited.

4. Instructions to perform I / O references are prohibited inside the enclave.

In the first generation of enclaves, the processor may run in ring 3 with IOPL set to zero when entering the enclave.

In order to preserve the programming environment when the enclave runs in a virtual or non-virtual environment, the instructions listed in Table 18-1 are illegal.

Table 18-1

Figure pct00067

Restrictions are imposed on the state inside the enclave. When entering the enclave, GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS are stored in the TCS area. The local value is cleared. Instructions that access or cause access to these registers will fail inside the enclave. GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS are stored again when leaving the enclave.

Table 18-2

Figure pct00068

The life of the enclave is divided into individual phases. The first step is enclave generation. The second step is the use of enclave. The final step is enclave destruction.

Creation and use of enclaves require the support of OS / VMM. Enclaves do not depend on OS / vmm for security, but will require OS / VMM to properly maintain any hardware data structure. Failure of the OS / VMM to maintain these structures may lead to a total failure of the enclave rather than leading to a loss of security.

Some instructions support verification of enclaves, sealing and unsealing of secret data, and permitting of authorized enclaves.

In a first step, the enclave can be securely configured and the internal software environment is set up for use by the application. Three instructions are used to create the enclave. The first command, ECREATE, sets the initial state environment. This command generates the enclave key, load, and encryption, and integrity checks the two pages used to store the enclave data structure. The second instruction, EADDPRE, adds a page of data to the enclave. This adds the necessary pages for the code, stack, and heap inside the enclave. The third command, EINIT, sets the internal software environment to a known state. Upon completion of this instruction, the enclave has moved to the second stage, use.

Prior to performing EINIT, the configuration software may have acquired a permit by performing EMKPERMIT or using a permit enclave.

The enclave is entered via the EENTER instruction. This instruction transitions the machine into enclave mode. This transfers control to the predefined entry point. The EEXIT instruction returns from an enclave to an external application. The EIRRET instruction returns to the enclave from the interrupt exit.

When entering the enclave via EENTER or EIRET, the following operations are performed by the instruction. Save and clear GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS. Save GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS on exit.

There is no instruction to destroy an enclave.

The EDBG_READ instruction performs an 8 byte read of the location inside the debug enclave. No access is allowed to non debug enclaves. The EDBG_WRITE instruction writes 8 bytes to a location inside the debug enclave. There is no access allowed to undebug the enclave.

The enclave page cache (EPC) is managed through two instructions. Two instructions load / store the EPC pages (ELPG and EWBINVPG).

EREPORT creates a cryptographically protected structure that holds enclave measurements. EGETKEY provides a means to retrieve enclave specific keys of varying types. EMKPERMIT is used to generate a permit for an authorized enclave.

Table 19-1

Figure pct00069

Note: External 2 : There is no model used for internal use, but there is nothing known about harming EMKPERMIT from inside.

1-3 3 : Future versions may enable entries from ring 0 to enclave.

Upon interruption, the processor state can be stored (and hidden) inside the enclave and the state is then cleared. Moreover, even the return address of the interrupt can be hidden.

Interrupts that occur while the enclave is running can push information onto the interrupt stack in the form expected by the operating system to avoid the need to change the OS code. To accomplish this, a pointer to the trampoline code is pushed onto an interrupt stack, such as a RIP. This trampoline code is finally returned to the enclave by the EENTER instruction with a specific parameter (q.v.).

The interrupt stack to be used is selected using the same rules as for non-SE mode:

If there is a privilege level change, the interrupt stack will be associated with the new ring.

If there is no privilege level change, the current untrusted stack is used.

If the IA-32e IST mechanism is used, the interrupt stack is selected using that method.

FIG. 23 illustrates an application and interrupt stack after an interrupt with a stack switch in one embodiment. Current storage state region frame 2300 includes an RSP register 2305. Thread control structure 2310 may include a count of state storage area 2312 and interrupt return routine 2314. The interrupt stack 2330 includes an SS register 2332, an RSP register 2334, a flag register 2336, a CS register 2338, an instruction register 2340, and an error code 2234. The interrupt stack 2330 may send data in its RSP register 2334 to the count of the application stack 2320 and the storage state area 2300. Error code 2342 comes from the RSP after push 2346. Interrupt routing routine 2314 and instruction register 2340 emit the per-thread trampoline of uRTS 2344.

In all cases, the choice of interrupt stack and the information pushed on it is consistent with non-SE operations. Figure 23 illustrates an application and interrupt stack after an interrupt with a stack switch. Interrupts without a stack switch use the application stack. In addition, the TCS pointer is located in RBX for later use by the EENTER instruction when resuming the enclave after interruption.

Interrupt Retrun Routine (TCS :: IRR) points to per-thread code that will later be returned to a particular thread. This pointer is pushed onto the interrupt stack with a return RIP. This results in a set of data structures that cause the IRET to be returned to the application where the interrupt return code (which contains a specialized EENTER instruction) is executed. EENTER takes an RBX register that is initialized (and saved by the OS) at the time of interrupt, and uses it as a TCS to reenter the enclave.

The following bits in RFLAGS are cleared after the register is pushed onto the interrupt stack:

CF Carry Flag SF Sign Flag

PF Parity Flag OF Overflow Flag

AF Adjust Flag DF Direction Flag

ZF Zero Flag

24 illustrates a possible method for implementing a stack of multiple state storage area slots in one embodiment of the invention. The thread control structure 2400 may include a next state storage area slot 2402, a current state storage area slot 2404, and a state storage area slot 2406. State storage area 0 2410, state storage area 1 2412, and state storage area N 2418 are three individually selected positions within the state storage area. The next state storage area slot 2402 specifies a location for use in the state storage area (state storage area 0 2410). Current state storage area slot 2404 specifies a location for use in state storage area (state storage area 1 2412). State storage area slot 2406 specifies a location for use in the state storage area (state storage area N 2418).

The state storage area holds the enclave state upon interruption. The SSA is a stack of multiple SSAs, as shown in Figures 19-3, because the interrupt can be delivered in user mode and then reenter into the enclave. The location of the state storage area to be used is controlled by three variables in the TCS: Number of State Save AreaSlots ( NSSA ) (which defines the total number of slots in the state storage area stack), Current State Save AreaSlot (CSSA) (which defines the current slot for use at the next interrupt), State Save Area ( SSA ) (set of storage area slots used to save processor state at interrupt time).

When an interrupt occurs while running on a thread inside an enclave, the microcode determines the storage area to use by examining TCS :: SSA and TCS :: CSSA. The processor state is saved and cleared (to avoid secret leaks) and TCS :: CSSA is incremented. As will be explained later, if the exception takes the final slot, it will not be possible to deliver the exception to the enclave.

Note: At EENTER, CSSA may be <NSSA to ensure that there is at least one storage area available for interrupts (unless EENTER is used to return from interrupts).

25 illustrates a portion of a state machine with state transitions for interrupts, faults, and traps in one embodiment of the invention. Possible states are inactive 2500, active 2510, advanced 2520, handled (EENTER illegal) 2530, and handling 2540. If EENTER dispatches to TCS: ENTRY 2502, inactive 2500 transitions to active 2510. When EEXIT 2504 occurs, active 2510 transitions to inactive 2500. When an interrupt, fault, or trap 1512 occurs, the activity 1510 transitions to an accepted 2520. When EIRET 2514 occurs, expected 2520 transitions to activity 2510. When EENTER dispatches to TCS: HANDLER 2524, an unconceived 2520 transitions to handling 2540. When EIRET 2522 occurs (2522), an unconceived (2520) transitions to handling (2540). If an interrupt, fault, or trap 2526 occurs, the handling 2540 transitions to an accepted 2520. If EEXIT 2532 occurs, handling 2540 transitions to handled 2530. If handling is interrupted within the enclave exception handler and EIRET 2534 occurs, handled 2530 transitions to handling 2540. If handling is not interrupting from the enclave exception handler and EIRET 2534 occurs, handled 2530 transitions to active 2510. Dotted line transitions 2522, 2526, and 2534 only occur when handling interrupts within the enclave exception handler.

25 shows a portion of an enclave state machine that handles interrupts. Interrupts begin with the push of a synthetic interrupt frame onto the optional stack switch and interrupt stack. If the event was an interrupt, the enclave enters the interrupted state. If the event was an exception, the enclave enters the exceptional state. These two states are distinguished to ensure delivery of enclave exceptions to the enclave and to prevent delivery of spurious exceptions by attacking application code.

In any transition to the interrupted state, untrusted code (application, OS or both) can only resume the enclave using EENTER / RETURN_FROM_INTERRUPT.

In any transition to the accepted state, the untrusted code (application, OS or both) is determined as follows.

Use EIRET to resume the enclave and return to the interrupted IP. This is, for example, the way page faults are handled. If the interrupt is due to a fault and nothing is done to correct the fault condition, the faulting instruction will be executed again and will fault again. However, the EIRET after the trap will return to the instruction following the trapping instruction.

Call the enclave exception handler.

• Give up the thread or enclave.

EENTER in the expected state proceeds to the handling state. EEXIT from the trap handler ( handling state) proceeds to the handled state. ENTER / NORMAL is illegal in this state. EIRET from the tampoline resumes the pushed, active or handling state on the SSA at the last interrupt.

The secure enclave instruction is divided into two opcodes: privileged opcode and non-privileged opcode. The instruction operation is determined by the value in RAX when the instruction is called.

Table 19-2

Figure pct00070

Table 19-3

Figure pct00071

The ECREATE command initiates a protected SECS. The source operator points to the page_info structure. The content page field points to an unprotected SECS structure. The SEC structure can be page aligned. The lower 12 bits and the boundary value of the SECS base may be zero. SECS is the address of an empty slot in the EPC. sec_info is the address of an unprotected sec_info structure. The corresponding sec_info flag field may be initialized appropriately.

Figure pct00072

Command input (s)

RAX 0x0

RBX PAGE_INFO

Pointer

Command output

The register RAX.TAX contains an error code if the instruction fails.

Instruction operation

Figure pct00073

Figure pct00074

Figure pct00075

Figure pct00076

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to US #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

Rex: Ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD ECREAT instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD ECREAT command not recognized in 8086 mode.

EADDPRE

Command Description

EADDPRE enables privileged software to copy pages outside the enclave to pages in the enclave specified by lin_addr, and the attributes of the enclave pages are set using the sec_info flag field.

As part of the instruction, the page is hashed and the resulting hash value is expanded into the measurement register of the enclave.

EADDPRE can only be performed on enclaves that have not yet been initialized by the EINIT instruction.

Command inputs

RAX 0x1

RBX PAGE_INFO

        Pointer

RCX EPC Linear Address

RDX SMAP Pointer

Instruction operation

Figure pct00077

Figure pct00078

Figure pct00079

Figure pct00080

Figure pct00081

Figure pct00082

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to US #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EADDPRE command is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EADDPRE command not recognized in 8086 mode.

EADDPOST

Command Description

EADDPOST causes privileged software to initialize the SMAP entry of the enclave specified by lin_addr, and set the attributes of the enclave page using the sec_info flag field.

Before an enclave can access a page, it can accept the page into the enclave using the EACCEPT instruction.

EADDPOST can only be performed on enclaves that have yet been initialized by the EINIT instruction.

Command inputs

RAX 0xa

RBX PAGE_INFO

        Pointer

RCX EPC Linear Address

RDX SMAP Pointer

Instruction operation

Figure pct00083

Figure pct00084

Figure pct00085

Figure pct00086

Figure pct00087

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to US #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EADDPOST command is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EADDPOST command is not recognized in 8086 mode.

EMKPERMIT

Command Description

Authenticate an enclave or license and generate a permit from it. If rbx == NULL, the certificate can be signed by Intel. Otherwise, the license can be signed by the key indicated in the rbx permit.

Command inputs

Figure pct00088

Instruction operation

Figure pct00089

Figure pct00090

Figure pct00091

Figure pct00092

Figure pct00093

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to US #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EINIT

Command Description

ENIT marks an enclave as ready for execution in a software environment. After a successful initialization, EENTER will be granted for the enclave.

Command inputs

RAX 0x2

RBX SECS Pointer

RCX PERMIT pointer

Instruction operation

Figure pct00094

Figure pct00095

Figure pct00096

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

ELPG

Command Description

This instruction is used to load a page into the Enclave Page Cache (EPC).

Command inputs

Linear address of the source page: page_info

Linear address of the destination: epc_la

Instruction operation

Figure pct00097

Figure pct00098
Figure pct00099

Figure pct00100

Return :

       If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons.

1. Page validation failed

2. Parameters are not aligned correctly

3. page_info parameter is malformed for SECS loading

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EWBINVPG

Command Description

This command is used to write dirty pages back from EPC to main memory.

Command inputs

page_info

epc_la

Instruction operation

Figure pct00101

Figure pct00102

Figure pct00103

Figure pct00104

Return :

If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

1. Certain EPC slots are not occupied

2. Parameters are not aligned correctly

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EUPSMAP

Command Description

This command checks and updates the version of the enclave page residing in the EPC.

Command inputs

leaf

epc_la

smap_la

Instruction operation

Figure pct00105

Figure pct00106

Figure pct00107

Retrun :

If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

1. TBD

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EREMOVE

Command Description

This command updates the SMAP when data is loaded into the EPCP.

Command inputs

leaf

epc_la

smap_la

Instruction operation

Figure pct00108

Figure pct00109

Figure pct00110

Figure pct00111

Retrun :

If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

2. TBD

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EADDSMAP

Command Description

This instruction is used to add a new page to SMAP when the enclave is already initialized.

Command inputs

page_info

epc_la

smap_la

Name of Offset value

LIN_ADDR MBZ

Linear address of the page where the SOURCE_PAGE page content is located

Linear address of secinfo structure for SEC_INFO page

Linear address of EPC in SECS empty slot

Instruction operation

Figure pct00112

Figure pct00113

Figure pct00114

Figure pct00115

Figure pct00116

Retrun :

If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

3. TBD

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EMODIFY

Command Description

This instruction modifies the SEC_INFO field so that the enclave can modify pages within that enclave. The enclave requests a change to the page but can accept that change to complete the process.

Command inputs

Figure pct00117

Instruction operation

Figure pct00118

Figure pct00119

Retrun :

If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

4. TBD

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EACCEPT

Command Description

Software inside the enclave uses this command to accept changes to the SEC_INFO field. This can cause SMAP to be updated with the new page type.

Command inputs

Figure pct00120

Instruction operation

Figure pct00121

Figure pct00122

Retrun :

If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

5. TBD

Affected Flags

Operation reference

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the current privilege level is not zero.

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD instruction not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD command not recognized in 8086 mode.

EENTER

Command Description

The EENTER instruction passes the execution to the enclave. At the end of the command, the CUP is running in enclave mode on the IP specified in the TCS oENTRY or oHANDLER.

EENTER checks whether the TCS is valid and available for the entry. The TCS and the corresponding SSA may reside in memory for instructions to proceed.

EENTER also checks the state machine to determine the entry type and checks that only one logic processor is active at a time inside the TCS.

RFLAGS.TF has a slightly modified behavior for EENTER. RFLAGS.TF is stored in TCS.SAVE_TF and then loaded from TCS.TF. Next, debug exceptions are conditionally generated depending on the RFLAGS.TFDML updated value. If the enclave is not in debug mode, debug register DR7 is stored and cleared in TCS.DR7. Similar for IA32_DEBUGCTL MSR.

Command inputs

RAX 0x4

RBX TCS Pointer

Command outputs

RCX EPC Linear Address

Instruction operation

Figure pct00123

Figure pct00124

Figure pct00125

Figure pct00126

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

RFLAGS . TF  motion

At the start of the execution of EENTER, the value of RFLAGS.TF is not affected by the trap of completion of EENTER. Instead, the value of RFLAGS.TF loaded from the TCS determines whether a trap is taken.

DR7  motion

If the enclave is not in debug mode, debug register DR7 is stored and cleared in TCS.DR7.

IA32 _ DEBUG _ CTL  motion

If the enclave is not in debug mode, the IA32_DEBUG_CTL MSR is stored in the TCS. DEBUG_CTL is cleared.

protect mode Exceptions

#GP (0) If the current privilege level is not 3.

If run inside the enclave.

If the processor is in the SMM.

If the segment register or limit register is not set correctly

If the thread is busy

Running in enclave mode

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD ECALL instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD ECALL command is not recognized in 8086 mode.

EEXIT

EEXIT goes out of the enclave.

Command Description

EEXIT disables enclave mode and branches to the location specified in RBX.

There are no registers affected by this instruction. If secrets are contained in any register, it is the Enclave software's responsibility to clear those registers.

RFLAGS.TF has a slightly modified behavior for EEXIT. RFLAGS.TF is loaded from TCS.SAVE_TF. Depending on the updated value of RFLAGS.TF, debug exceptions are conditionally generated.

If the enclave is not in debug mode, debug register DR7 is loaded from TCR.DR7. This behavior and the RFLAGS.TFDML behavior is documented in more detail in ???.

Command inputs

RAX 0x6

RBX Target Address

Instruction operation

Figure pct00127

Figure pct00128

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

RFLAGS . TF  motion

At the start of the execution of EENTER, the value of RFLAGS.TF is not affected by the trap of completion of EENTER. Instead, the value of RFLAGS.TF loaded from the SSA determines whether a trap is taken.

DR7  motion

If the enclave is not in debug mode, debug register DR7 is loaded from TCS.DR7.

IA32 _ DEBUG _ CTL  motion

If the enclave is not in debug mode, the IA32_DEBUG_CTL MSR is loaded from the TCS.

DEBUG_CTL.

protect mode Exceptions

#GP (0) If the current privilege level is not 3.

If run outside the enclave.

If the processor is in the SMM.

If the segment register or limit register is not set correctly

If thread busy is not in ACTIVE or HANDLED state

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EEXIT instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EEXIT command is not recognized in 8086 mode.

EIRET

Command Description

The EIRET instruction resumes execution of an interrupted enclave due to an exception or interrupt using the machine state previously stored in the SSA. EIRET checks that the TCS is valid and available for resume. The TCS and its corresponding SSA may reside in memory for instructions to proceed. EIRET also checks the state machine to determine the entry type, and checks that only one logic processor is active at a time inside the TCS.

If RFLAGS.TF is set on EIRET, the debug exception will occur at the completion of the instruction, that is, during normal TF behavior. This exception will be reported to occur inside the enclave (in normal SE-defined format) without any instructions being executed internally. Since EIRET stores RFLAGS back from SSA, TF can be set at the end of EIRET. In this case, the TF will affect the following instruction; Again, normal TF behavior.

Command inputs

RAX 0x5

RBX TCS Pointer

Instruction operation

Figure pct00129

Figure pct00130

Figure pct00131

Figure pct00132

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

RFLAGS . TF  motion

If RFLAGS.TF was set at the beginning of the EIRET run, #DB will occur after completion. The exception will be reported that no TF is set in the RIP to which control has transferred. In fact, no forward progression in the enclave will occur.

As a normal operation part of EIRET, RFLAGS is stored back from the SSA copy. The resulting TF is set, and #DB will occur after execution of the target instruction inside the enclave.

These behaviors match those of normal IA IRET instructions.

DR7  motion

DR7 is saved back from the previously saved SSA copy at the last interrupt or exception.

IA32 _ DEBUG _ CTL  motion

The IA32_DEBUG_CTL MSR is saved back from the SSA copy already stored at the last interrupt or exception.

protect mode Exceptions

#GP (0) If the current privilege level is not 3.

If run inside the enclave.

If the processor is in the SMM.

If the segment register or limit register is not set correctly

If thread is busy

Running in enclave mode

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD ECALL instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD ECALL command is not recognized in 8086 mode.

EREPORT

The EREPORT instruction reports a measurement on enclave content.

Command Description

EREPORT retrieves the enclave measurement registers, their capabilities, and their debug status (flag). All these values are protected using a symmetric message authentication code that can be verified using the REPORT key. Enclaves requesting a REPORT key may have the ability set appropriately in their SECS to retrieve it using the EGETKEY command.

The result of this command is integrated into the destination location, output_buffer_la.

Command inputs

RAX 0x6

RBX output_buffer_la

RCX userInput_la

Instruction operation

Figure pct00133

Figure pct00134

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EREPORT command is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EREPORT command is not recognized in 8086 mode.

ERDMR

The ERDMR instruction reads the measurement register value outside of the enclave SECS.

Command Description

This instruction can only be executed from outside the enclave. If the SECS points to a valid SECS page, this command outputs the contents of the enclave measurement register to the address specified by output_buffer_la.

Command inputs

RAX 0x8

RBX sec_la

RCX output_buffer_la

Instruction operation

Figure pct00135

Figure pct00136

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EREPORT command is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EREPORT command is not recognized in 8086 mode.

EGETKEY

Used by enclave mode to return a specific key from the processor key hierarchy.

Command Description

The required key is specified using the KeyRequest structure, whose address is provided as input. This address can be naturally aligned.

The output is always a 256 bit data value. output_la needs to be sorted naturally for this value.

Inputs

RAX 0x02

RBX request_la

RCX output_buffer_la

Instruction operation

Figure pct00137

Figure pct00138

Figure pct00139

Figure pct00140

Figure pct00141

Figure pct00142

Figure pct00143

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EGETKEY instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EGETKEY command not recognized in 8086 mode.

ERDTCSPTR

Command Description

The ERDTCSPTR instruction is used to read the current TCS linear address into the RBX.

Command output

RAX 0x3

Command output

RBX Current TCS Pointer

Instruction operation

Figure pct00144

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to US #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

If the #UD enclave is not enabled,

If run outside the #GP (0) enclave.

Physical address mode Exceptions

#UD ERDTCSPTR instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD ERDTCSPTR command is not recognized in 8086 mode.

EDBGRD

Command Description

The EDBGRD instruction is used to read 8 bytes from the debug enclave.

Command inputs

epc_la

dest

Instruction operation

Figure pct00145

Figure pct00146

Affected Flags

none

Prefix  use

Lock: attributed to UD #

REP: attributed to UD #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#GP (0) If the enclave is not marked for debug

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EDBGRD command is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EDBGRD command is not recognized in 8086 mode.

EDBGWR

Command Description

The EDBGWR instruction is used to write 8 bytes to debug the enclave page.

Command inputs

src

epc_la

Instruction operation

Figure pct00147

Figure pct00148

Affected Flags

none

Prefix  use

TBD

protect mode Exceptions

If the GP (0) enclave is not marked for debug

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

Physical address mode Exceptions

#UD EDBGWR instruction is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EDBGWRITE command is not recognized in 8086 mode.

ERDINFO

The ERDINFO instruction returns information about the contents of the enclave page cache.

Command Description

If executed in an enclave, EREPORT reports its capability and debug status (flag) to the enclave measurement register. All these values are protected using a symmetric message authentication code that can be verified using the EVERIFYREPORT command.

The result of this command is deposited at the destination location, output_buffer_la.

Command inputs

epc_la // Linear address of the page inside the EPC

page_info // SEC_INFO field inside page_info can be populated with a valid pointer // naturally aligned SEC_INFO structure

Instruction operation

Figure pct00149

Figure pct00150

Affected Flags

RFLAGS.ZF

Prefix  use

Lock: attributed to UD #

REP: attributed to US #

Segment Override: N / A

Operator size: attributed to UD #

Address size: ignored

protect mode Exceptions

#PF (Fault-Code) When a page fault occurs in an access memory operator.

If #UD enclaves are not enabled.

If #GP CPL! = 0

FAULT epc_la does not point within EPC

Physical address mode Exceptions

#UD EREPORT command is not recognized in real address mode.

Virtual 8086 mode Exceptions

#UD EREPORT command is not recognized in 8086 mode.

Routine reference

-------------------------------------------------- -------------------

Exits

This section provides pseudo code for exit processing. This code is called when an exit from an enclave is not planned by the enclave code. Enclave execution resumes where it left off. The information needed to resume is stored on the external stack. The architectural state of the processor is stored in the appropriate storage area.

calculate

Figure pct00151

Figure pct00152

acquire reader lock

RW locks allow the logic processor to access shared resources and provide two modes in which threads can access shared resources:

Shared mode grants multiple read logic access to multiple reader logic processors, which allows them to read data simultaneously from shared resources.

Proprietary mode allows one writer logic processor one read / write access at a time. When a lock is acquired in exclusive mode, no other thread can access the shared resource until the writer releases the lock.

A single RW lock can be obtained in either mode; The reader logic processor may acquire it in shared mode while the writer logic processor may acquire it in proprietary mode. Logic processors are granted request rights in a fair order.

Here is the RW lock function:

acquire_reader_lock, release_reader_rock, acquire_writer_lock, release_lock.

Subroutine Description

Acquire the lock in shared mode.

Subroutine input

volatile se_rw_lock_t * l

Subroutine operation

Figure pct00153

Figure pct00154

Affected Flag

none

Exceptions

none

release reader lock

Subroutine Description

Unlock acquired in shared mode

Subroutine inputs

volatile se_rw_lock_t * 1

Subroutine operation

Figure pct00155

Affected Flag

none

Exceptions

none

acquire writer lock

Subroutine Description

Acquire lock in exclusive mode

Subroutine inputs

volatile se_rw_lock_t * 1

Subroutine operation

Figure pct00156

Affected Flag

none

Exceptions

none

release writer lock

Subroutine Description

Unlock acquired in exclusive mode

Subroutine inputs

volatile se_rw_lock_t * 1

Subroutine operation

Figure pct00157

Affected Flag

none

Exceptions

none

xutranslate

Subroutine Description

This subroutine is actually hardware that uCode exposes and adds PMH address translation function to xuCode. XUTRANSLATE is an xuOp that takes a PMH context, and a linear address as input, and generates the final physical address as output. If the PMH encounters any fault condition during the page table walk, they are reported as xuCode. The details of this xuOp are beyond the scope of this document.

Subroutine inputs

TBD

Subroutine operation

Affected Flag

none

Exceptions

none

deriveKey

Subroutine Description

This subroutine is used to generate a key by performing a CMAC operation over the DerivationBuffer using the identified key. DerivationBuffer needs to be a number of 128 bits.

Subroutine inputs

pBaseKey-the base key used

derivationBuffer- fixed size buffer to be hashed

Subroutine operation

Figure pct00158

Affected Flag

none

Exceptions

none

Claims (15)

  1. As a processor,
    Execution logic for performing at least a first instruction to move the protected data between an enclave page cache (EPC) and a second storage area during execution of a program that accesses protected data; , The program is running in protected mode
    Processor.
  2. The method of claim 1,
    A security map (SMAP) helps to ensure the integrity of the program when the program is stored on a hard disk drive or protected memory.
    Processor.
  3. As a processor,
    Execution logic for performing a first instruction to identify a software thread executing in a secure enclave, wherein the first instruction informs a user's program of the identity of the software thread.
    Processor.
  4. As a processor,
    Execution logic for performing at least a first instruction to dynamically access at least one information field to determine the integrity of data stored in the secure clave, wherein the at least one information field comprises a security map (SMAP) field and a security; Contains information (SEC_INFO) field
    Processor.
  5. As a processor,
    Execution logic for performing a first instruction to report a state of a secure enclave stored in memory to either a local agent or a remote agent.
    Processor.
  6. As a processor,
    A crypto memory aperture (CMA) for protecting the software program against attacks when the software program is running; And a security map (SMAP) for protecting the software program when the software program is not running.
    Processor.
  7. As a processor,
    includes execution logic for executing at least one secure enclave access instruction to allocate or deallocate memory or software threads corresponding to the inside (?) _ a secure enclave.
    Processor.
  8. As a processor,
    A layer protection tree, SMAP, to enable multiple memory updates within a single processor cycle of secure enclave
    Processor.
  9. As a processor,
    Execution logic for performing a first instruction to provide a unique key to a secure enclave
    Processor.
  10. As a processor,
    Logic to perform a first instruction to establish a trusted environment to be managed by an untrusted agent
    Processor.
  11. As a processor,
    Logic for performing instructions to validate a license for accessing a secure enclave, wherein the instruction compares the size of the enclave with a size defined by a license certificate to determine the validity of the license.
    Processor.
  12. A processor comprising logic to enable a user-level policy for a secure enclave, the logic being controlled by control bits.
    Processor.
  13. Logic for performing at least one instruction to enable a user to access at least one instance of a secure enclave to be licensed
    Processor.
  14. As a processor,
    Logic for performing at least one instruction to enable debugging of the secure enclave, wherein the at least one instruction causes the enclave security to be violated only for enclaves to be enabled to be debugged.
    Processor.
  15. As a processor,
    Processor logic for executing at least one instruction to allocate memory pages to an enclave page cache (EPC) or deallocate from the EPC.
KR1020127016450A 2009-12-22 2009-12-22 Method and apparatus to provide secure application execution KR101457355B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2009/069212 WO2011078855A1 (en) 2009-12-22 2009-12-22 Method and apparatus to provide secure application execution

Publications (2)

Publication Number Publication Date
KR20120099472A true KR20120099472A (en) 2012-09-10
KR101457355B1 KR101457355B1 (en) 2014-11-04

Family

ID=44196072

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020127016450A KR101457355B1 (en) 2009-12-22 2009-12-22 Method and apparatus to provide secure application execution

Country Status (7)

Country Link
JP (1) JP5443599B2 (en)
KR (1) KR101457355B1 (en)
CN (1) CN102473224B (en)
BR (1) BRPI0924512A2 (en)
DE (1) DE112009005466T5 (en)
GB (2) GB2550698B (en)
WO (1) WO2011078855A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014084914A1 (en) * 2012-11-30 2014-06-05 Intel Corporation Secure environment for graphics processing units
KR20140118862A (en) * 2013-03-31 2014-10-08 인텔 코오퍼레이션 Instructions and logic to provide advanced paging capabilities for secure enclave page caches
KR20150105983A (en) * 2013-03-15 2015-09-18 인텔 코포레이션 Method, apparatus, system, and computer readable medium to provide secure operation
US20150278528A1 (en) * 2014-03-27 2015-10-01 Intel Corporation Object oriented marshaling scheme for calls to a secure region
US9536063B2 (en) 2013-10-24 2017-01-03 Intel Corporation Methods and apparatus for protecting software from unauthorized copying

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9087200B2 (en) 2009-12-22 2015-07-21 Intel Corporation Method and apparatus to provide secure application execution
US8739177B2 (en) 2010-06-21 2014-05-27 Intel Corporation Method for network interface sharing among multiple virtual machines
US9053042B2 (en) 2012-06-27 2015-06-09 Intel Corporation Method, system, and device for modifying a secure enclave configuration without changing the enclave measurement
AU2013355124B2 (en) 2012-12-07 2018-03-22 Vertex Pharmaceuticals Incorporated Compounds useful as inhibitors of ATR kinase
US9747102B2 (en) 2012-12-28 2017-08-29 Intel Corporation Memory management in secure enclaves
US9323686B2 (en) * 2012-12-28 2016-04-26 Intel Corporation Paging in secure enclaves
US20140189246A1 (en) * 2012-12-31 2014-07-03 Bin Xing Measuring applications loaded in secure enclaves at runtime
JP6055561B2 (en) * 2013-03-06 2016-12-27 インテル・コーポレーション A starting point of trust for measuring virtual machines
US9087202B2 (en) 2013-05-10 2015-07-21 Intel Corporation Entry/exit architecture for protected device modules
US20160085955A1 (en) * 2013-06-10 2016-03-24 Doosra, Inc. Secure Storing and Offline Transferring of Digitally Transferable Assets
US9338918B2 (en) 2013-07-10 2016-05-10 Samsung Electronics Co., Ltd. Socket interposer and computer system using the socket interposer
US20150033034A1 (en) * 2013-07-23 2015-01-29 Gideon Gerzon Measuring a secure enclave
US9698989B2 (en) * 2013-07-23 2017-07-04 Intel Corporation Feature licensing in a secure processing environment
US9767044B2 (en) * 2013-09-24 2017-09-19 Intel Corporation Secure memory repartitioning
US9501668B2 (en) 2013-09-25 2016-11-22 Intel Corporation Secure video ouput path
US10121144B2 (en) * 2013-11-04 2018-11-06 Apple Inc. Using biometric authentication for NFC-based payments
CN105723377B (en) * 2013-12-17 2019-06-04 英特尔公司 For kernel mode using safety zone
WO2015094277A1 (en) 2013-12-19 2015-06-25 Intel Corporation Technologies for supporting multiple digital rights management protocols on a client device
EP3084667A4 (en) * 2013-12-19 2017-07-26 Intel Corporation Policy-based trusted inspection of rights managed content
US9448950B2 (en) 2013-12-24 2016-09-20 Intel Corporation Using authenticated manifests to enable external certification of multi-processor platforms
US9413765B2 (en) 2014-03-25 2016-08-09 Intel Corporation Multinode hubs for trusted computing
US9703733B2 (en) * 2014-06-27 2017-07-11 Intel Corporation Instructions and logic to interrupt and resume paging in a secure enclave page cache
US9705892B2 (en) 2014-06-27 2017-07-11 Intel Corporation Trusted time service for offline mode
CN105573831B (en) * 2014-10-13 2019-11-26 龙芯中科技术有限公司 Data transfering method and device
US10181027B2 (en) * 2014-10-17 2019-01-15 Intel Corporation Interface between a device and a secure processing environment
US9940456B2 (en) 2014-12-16 2018-04-10 Intel Corporation Using trusted execution environments for security of code and data
US9606940B2 (en) 2015-03-27 2017-03-28 Intel Corporation Methods and apparatus to utilize a trusted loader in a trusted computing environment
US9875189B2 (en) 2015-06-12 2018-01-23 Intel Corporation Supporting secure memory intent
US10061941B2 (en) 2015-08-19 2018-08-28 Altera Corporation Systems and methods for multiport to multiport cryptography
US10031861B2 (en) * 2015-09-25 2018-07-24 Intel Corporation Protect non-memory encryption engine (non-mee) metadata in trusted execution environment
US9798641B2 (en) * 2015-12-22 2017-10-24 Intel Corporation Method to increase cloud availability and silicon isolation using secure enclaves
GB2555961B (en) 2016-11-14 2019-08-28 Google Llc System of enclaves
GB2564097B (en) * 2017-06-28 2019-10-23 Advanced Risc Mach Ltd Memory region locking
GB2563882B (en) * 2017-06-28 2019-10-23 Advanced Risc Mach Ltd Interrupting sequences of command actions performed upon memory regions
KR102080497B1 (en) * 2017-10-31 2020-02-24 삼성에스디에스 주식회사 Method for Exchanging Data between Channels of System based on Multi-Channel Blockchain and System thereof
US20190140846A1 (en) * 2017-11-03 2019-05-09 Microsoft Technology Licensing, Llc Provisioning trusted execution environment(s) based on chain of trust including platform
US10552344B2 (en) 2017-12-26 2020-02-04 Intel Corporation Unblock instruction to reverse page block during paging
US20190251257A1 (en) * 2018-02-15 2019-08-15 Intel Corporation Mechanism to prevent software side channels
US20190042324A1 (en) * 2018-03-30 2019-02-07 Intel Corporation Techniques for dynamic resource allocation among cryptographic domains
CN110032883B (en) * 2019-01-31 2020-05-29 阿里巴巴集团控股有限公司 Method, system and node for realizing privacy protection in block chain
CN110008736A (en) * 2019-01-31 2019-07-12 阿里巴巴集团控股有限公司 The method and node, storage medium of secret protection are realized in block chain
CN110032885B (en) * 2019-02-19 2020-03-06 阿里巴巴集团控股有限公司 Method, node and storage medium for implementing privacy protection in block chain
SG11202000825YA (en) 2019-04-19 2020-02-27 Alibaba Group Holding Ltd Methods and devices for executing trusted applications on processor with support for protected execution environments

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4098478B2 (en) * 2001-01-31 2008-06-11 株式会社東芝 Microprocessor
JP2002353960A (en) * 2001-05-30 2002-12-06 Fujitsu Ltd Code performing device and code distributing method
JP4263976B2 (en) * 2003-09-24 2009-05-13 株式会社東芝 On-chip multi-core tamper resistant processor
US7934076B2 (en) * 2004-09-30 2011-04-26 Intel Corporation System and method for limiting exposure of hardware failure information for a secured execution environment
CN101116081A (en) * 2005-02-11 2008-01-30 通用数据保护公司 Method and system for microprocessor data security
US20070172053A1 (en) * 2005-02-11 2007-07-26 Jean-Francois Poirier Method and system for microprocessor data security
US7657754B2 (en) * 2005-12-08 2010-02-02 Agere Systems Inc Methods and apparatus for the secure handling of data in a microcontroller
JP4795812B2 (en) * 2006-02-22 2011-10-19 富士通セミコンダクター株式会社 Secure processor
US8973094B2 (en) * 2006-05-26 2015-03-03 Intel Corporation Execution of a secured environment initialization instruction on a point-to-point interconnect system
JP2008033457A (en) * 2006-07-26 2008-02-14 Internatl Business Mach Corp <Ibm> Method and central processing unit for processing encrypted software
JP4912921B2 (en) * 2007-02-27 2012-04-11 富士通セミコンダクター株式会社 Secure processor system, secure processor, and secure processor system control method

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014084914A1 (en) * 2012-11-30 2014-06-05 Intel Corporation Secure environment for graphics processing units
US9519803B2 (en) 2012-11-30 2016-12-13 Intel Corporation Secure environment for graphics processing units
KR20150105983A (en) * 2013-03-15 2015-09-18 인텔 코포레이션 Method, apparatus, system, and computer readable medium to provide secure operation
KR20140118862A (en) * 2013-03-31 2014-10-08 인텔 코오퍼레이션 Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US9536063B2 (en) 2013-10-24 2017-01-03 Intel Corporation Methods and apparatus for protecting software from unauthorized copying
US20150278528A1 (en) * 2014-03-27 2015-10-01 Intel Corporation Object oriented marshaling scheme for calls to a secure region
US9864861B2 (en) 2014-03-27 2018-01-09 Intel Corporation Object oriented marshaling scheme for calls to a secure region

Also Published As

Publication number Publication date
KR101457355B1 (en) 2014-11-04
WO2011078855A1 (en) 2011-06-30
GB201118724D0 (en) 2011-12-14
GB2550698B (en) 2018-04-11
GB2481563A (en) 2011-12-28
CN102473224B (en) 2016-10-12
BRPI0924512A2 (en) 2016-03-01
GB2550698A (en) 2017-11-29
GB2481563B (en) 2017-07-19
JP5443599B2 (en) 2014-03-19
JP2012530961A (en) 2012-12-06
WO2011078855A9 (en) 2011-09-09
CN102473224A (en) 2012-05-23
DE112009005466T5 (en) 2012-10-31
GB201709341D0 (en) 2017-07-26

Similar Documents

Publication Publication Date Title
US10572689B2 (en) Method and apparatus for secure execution using a secure memory partition
Götzfried et al. Cache attacks on Intel SGX
Mashtizadeh et al. CCFI: Cryptographically enforced control flow integrity
US9483662B2 (en) Method and apparatus for remotely provisioning software-based security coprocessors
US9846787B2 (en) System and method for implementing a trusted dynamic launch and trusted platform module (TPM) using secure enclaves
Santos et al. Using ARM TrustZone to build a trusted language runtime for mobile applications
JP2016197436A (en) Execution of secured environment initialization instruction on point-to-point interconnect system
US10114958B2 (en) Protected regions
US9767271B2 (en) System and method for validating program execution at run-time
Criswell et al. Virtual ghost: Protecting applications from hostile operating systems
Ferraiuolo et al. Komodo: Using verification to disentangle secure-enclave hardware from software
Fletcher et al. A secure processor architecture for encrypted computation on untrusted programs
Costan et al. Intel SGX Explained.
Awad et al. Silent shredder: Zero-cost shredding for secure non-volatile main memory controllers
McKeen et al. Innovative instructions and software model for isolated execution.
US10360411B2 (en) Secure processing unit systems and methods
CN103210396B (en) Comprise the method and apparatus of the framework for the protection of sensitive code and data
US20190171476A1 (en) System and Method for Self-Protecting Data
JP2015057722A (en) Platform firmware armoring technology
US9762399B2 (en) System and method for validating program execution at run-time using control flow signatures
US10438023B2 (en) Pipeline processor data and attribute register, secure emulation logic, gating
US9575903B2 (en) Security perimeter
EP2577449B1 (en) Method and apparatus for trusted execution in infrastructure as a service cloud environments
Szefer et al. Architectural support for hypervisor-secure virtualization
US9705677B2 (en) Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant