Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 139
NEXT GENERATION PERFORMANCE MONITORING UNIT (PMU)
8.7.3
MSRs
Table 8-7. Architectural MSRs
Register
Address
Architectural MSR Name / Bit Fields
MSR/Bit Description
Reset
(Former MSR Name)
Value
Hex
Dec
1902H,
6402,
IA32_PMC_GPn_CFG_B
ACR Reload Configuration for PMCx
1906H,
6406,
0
PMC0
0
190AH,
6410,
Reload PMCx on overflow of PMC0.
…
1902H
6402
1
PMC1
0
+(4*n)
+(4*n)
Reload PMCx on overflow of PMC1.
0
n
PMCn
0
Reload PMCx on overflow of PMCn.
31:n+1
Reserved.
0
32
FIXED_CTR0
0
Reload PMCx on overflow of FIXED_CTR0.
33
FIXED_CTR1
0
Reload PMCx on overflow of FIXED_CTR1.
0
32+m
FIXED_CTRm
0
Reload PMCx on overflow of FIXED_CTRm.
62:32+m+1
Reserved.
0
63
PREVENT_RELOAD
0
Do not allow other counters to reload based on overflow of
PMCx.
1903H,
6403,
IA32_PMC_GPn_CFG_C
Extended Performance Event Selector for GP Counter x
1907H,
6407,
31:0
PMCx Reload Value
0
…
1903H
6403
63:32
Reserved.
0
+(4*n)
+(4*n)
1982H,
6530,
IA32_PMC_FXm_CFG_B
ACR Reload Configuration for Fixed CTRx
1986H,
6534,
0
PMC0
0
198AH,
6538,
Reload PMCx on overflow of PMC0.
…
1982H
6530
1
PMC1
0
+(4*m)
+(4*m)
Reload PMCx on overflow of PMC1.
0
n
PMCn
0
Reload PMCx on overflow of PMCn.
31:n+1
Reserved.
0
32
FIXED_CTR0
0
Reload PMCx on overflow of FIXED_CTR0.
33
FIXED_CTR1
0
Reload PMCx on overflow of FIXED_CTR1.
Document Number: 319433-050
8-13
NEXT GENERATION PERFORMANCE MONITORING UNIT (PMU)
Table 8-7. Architectural MSRs (Contd.)
Register
Address
Architectural MSR Name / Bit Fields
MSR/Bit Description
Reset
(Former MSR Name)
Value
Hex
Dec
0
32+m
FIXED_CTRm
0
Reload PMCx on overflow of FIXED_CTRm.
62:32+m+1
Reserved.
0
63
PREVENT_RELOAD
0
Do not allow other counters to reload based on overflow of
CTRx.
1983H,
6531,
IA32_PMC_FXm_CFG_C
Extended Performance Event Selector for Fixed Counter x
1987H,
6535,
31:0
FIXED_CTRx Reload Value
0
…
1983H
6531
63:32
Reserved.
0
+(4*m)
+(4*m)
8-14
Document Number: 319433-050
LINEAR ADDRESS SPACE SEPARATION (LASS)
CHAPTER 9
LINEAR ADDRESS SPACE SEPARATION (LASS)
This chapter describes a new feature called linear address space separation (LASS).
9.1
INTRODUCTION
Chapter 4 of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A describes paging,
which is the process of translating linear addresses to physical addresses and determining, for each translation, the
linear address’s access rights; these determine what accesses to a linear address are allowed.
Every access to a linear address is either a supervisor-mode access or a user-mode access. A linear address’s
access rights include an indication of whether address is a supervisor-mode address or a user-mode address.
Paging prevents user-mode accesses to supervisor-mode addresses; in addition, there are features that can
prevent supervisor-mode accesses to user-mode addresses. (These features are supervisor-mode execution
prevention - SMEP - and supervisor-mode access prevention - SMAP.) In most cases, the blocked accesses
cause page-fault exceptions (#PF); for some cases (e.g., speculative accesses), the accesses are dropped without
fault.
With these mode-based protections, paging can prevent malicious software from directly reading or writing
memory inappropriately. To enforce these protections, the processor must traverse the hierarchy of paging struc-
tures in memory. Unprivileged software can use timing information resulting from this traversal to determine
details about the paging structures, and these details may be used to determine the layout of supervisor memory.
Linear-address space separation (LASS) is an independent mechanism that enforces the same mode-based protec-
tions as paging but without traversing the paging structures. Because the protections enforced by LASS are applied
before paging, “probes” by malicious software will provide no paging-based timing information.
LASS is based on a linear-address organization established by many operating systems: all linear addresses whose
most significant bit is 0 (“low” or “positive” addresses) are user-mode addresses, while all linear addresses whose
most significant bit is 1 (“high” or “negative” addresses) are supervisor-mode addresses. An operating system
should enable LASS only if it uses this organization of linear addresses.
9.2
ENUMERATION AND ENABLING
Support for LASS is enumerated with CPUID.(EAX=07H.ECX=1):EAX.LASS[bit 6].
If a processor enumerates CPUID.(EAX=07H.ECX=1):EAX.LASS[bit 6] as 1, software can set CR4.LASS[bit 27].
Setting CR4.LASS to 1 enables LASS in IA-32e mode (when IA32_EFER.LMA = 1). LASS is not used in legacy mode,
even if CR4.LASS = 1.
9.3
OPERATION OF LINEAR-ADDRESS SPACE SEPARATION
This section describes the operation of linear-address space separation (LASS). The discussion in this section
applies only if IA32_EFER.LMA = CR4.LASS = 1. (If either of those control bits is zero, LASS does not apply.)
As indicated in Section 9.1, LASS enforces mode-based protections similar to those enforced by paging. Violations
of these protections are called LASS violations. The processor will consult neither the paging structures nor the
TLBs for an access that causes a LASS violation.
Like paging, LASS violations typically result in faults. Instead of page faults (#PF), an access causing a LASS viola-
tion results in the same fault that would occur if the access used an address that was not canonical relative to the
current paging mode. In most cases, this is a general protection exception (#GP); for stack accesses (those due to
stack-oriented instructions, as well as accesses that implicitly or explicitly use the SS segment register), it would
be a stack fault (#SS).
Document Number: 319433-050
9-1
LINEAR ADDRESS SPACE SEPARATION (LASS)
Some accesses do not cause faults when they would violate the mode-based protections established by paging.
These include prefetches (e.g., those resulting from execution of one of the PREFETCHh instructions), executions
of the CLDEMOTE instruction, and accesses resulting from the speculative fetch or execution of an instruction. Such
an access may cause a LASS violation; if it does, the access is not performed but no fault occurs. (When such an
access would violate the mode-based protections of paging, the access is not performed but no page fault occurs.)
In 64-bit mode, LASS violations have priority just below that of canonicality violations; in compatibility mode, they
have priority just below that of segment-limit violations.
The remainder of this section describes how LASS applies to different types of accesses to linear addresses.
Chapter 4, “Paging,” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A provides full
definitions of these access types. The sections below discuss specific LASS violations based on bit 63 of a linear
address. For a linear address with only 32 bits (or 16 bits), the processor treats bit 63 as if it were 0.
9.3.1
Data Accesses
A linear-address access is a data access if it is not for the fetch of an instruction. Such an access is a user-mode
access if CPL = 3 and the access is not one that implicitly accesses a system data structure (e.g., the global
descriptor table); it is a supervisor-mode access if CPL < 3 or if it implicitly accesses a system data structure.1
A user-mode data access causes a LASS violation if it would access a linear address of which bit 63 is 1. It is
expected that the operating system will configure paging so that any such address is a supervisor-mode address.
A supervisor-mode data access may cause a LASS violation if it would access a linear address of which bit 63 is 0.
It is expected that the operating system will configure paging so that any such address is a user-mode address.
A supervisor-mode data access causes a LASS violation only if supervisor-mode access protection is enabled
(because CR4.SMAP = 1) and either RFLAGS.AC = 0 or the access implicitly accesses a system data structure.
9.3.2
Instruction Fetches
Instruction fetches are always performed with linear addresses. An instruction fetch is user-mode if CPL = 3 and
is supervisor mode if CPL < 3.
A user-mode instruction fetch causes a LASS violation if it would fetch an instruction using a linear address of which
bit 63 is 1.
A supervisor-mode instruction fetch causes a LASS violation if it would accesses a linear address of which bit 63
is 0.
(Paging blocks supervisor-mode instruction fetches from user-mode linear addresses only if supervisor-mode
execution protection has been enabled by setting CR4.SMEP to 1. Such instructions fetches cause LASS violations
regardless of the setting of CR4.SMEP.)
It was noted earlier that LASS violations produce the same faults as canonicality violations and with a similar
priority. LASS violations differ from canonicality violations in particular way as regards instruction flow. An instruc-
tion that loads RIP (a branch instruction) causes a general-protection exception (#GP) as a fault if it would load RIP
with a value that is not canonical relative to the current paging mode; RIP is not updated, and the fault is reported
on the branch instruction. In contrast, branch instructions do not check the target RIP for LASS violations, and thus
LASS does not prevent branch instructions from completing. Fetch of the next instruction (at the target RIP) may
cause a LASS violation and a #GP. In that case, the fault is reported on the branch target, not the branch instruc-
tion.
1. The WRUSS instruction is an exception; although it can be executed only if CPL = 0, the processor treats its shadow-stack accesses
as user accesses.
9-2
Document Number: 319433-050
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
CHAPTER 10
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
10.1
INTRODUCTION
Remote Atomic Operations (RAO) are a set of instructions to improve synchronization performance. RAO is espe-
cially useful in multiprocessor applications that have a set of characteristics commonly found together:
• A need to update, i.e., read and modify, one or more variables atomically, e.g., because multiple processors
may attempt to update the same variable simultaneously.
• Updates are not expected to be interleaved with other reads or writes of the variables.
• The order in which the updates happen is unimportant.
One example of this scenario is a multiprocessor histogram computation, where multiple processors cooperate to
compute a shared histogram, which is then used in the next phase of computation. This is described in more detail
in Section 10.8.1.
RAO instructions aim to provide high performance in this scenario by:
• Atomically updating memory without returning any information to the processor itself.
• Relaxing the ordering of RAO instructions with respect to other updates or writes to the variables.
RAO instructions are defined such that, unlike conventional atomics (e.g., LOCK ADD), their operations may be
performed closer to memory, such as at a shared cache or memory controller. Performing operations closer to
memory reduces or even eliminates movement of data between memory and the processor executing the instruc-
tion. They also have weaker ordering guarantees than conventional atomics. This facilitates execution closer to
memory, and can also lead to reduced stalls in the processor pipeline. These properties mean that using RAO
instead of conventional atomics may provide a significant performance boost for the scenario outlined above.
10.2
INSTRUCTIONS
The current set of RAO instructions can be found in Chapter 2, “Instruction Set Reference, A-Z.” These instructions
include integer addition and bitwise AND, OR, and XOR. These operations may be performed on 32-bit (double-
word) or 64-bit (quadword) data elements. The destination, which is also one of the inputs, is always a location in
memory. The other input is a general-purpose register, ry, in Table 10-1. The instructions do not change any regis-
ters or flags.
Table 10-1. RAO Instructions
Instruction
Operation
Function
Data Types
AADD
Atomic addition
mem = mem + ry
Doubleword, quadword
AAND
Atomic bitwise AND
mem = mem AND ry
Doubleword, quadword
AOR
Atomic bitwise OR
mem = mem OR ry
Doubleword, quadword
AXOR
Atomic bitwise XOR
mem = mem XOR ry
Doubleword, quadword
10.3
ALIGNMENT REQUIREMENTS
The memory location updated by an RAO instruction must be naturally aligned. That is, a doubleword update must
be four-byte aligned and a quadword update must be eight-byte aligned. This facilitates implementations closer to
memory; otherwise, a single update may straddle a cache line boundary.
Document Number: 319433-050
10-1
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
10.4
MEMORY ORDERING
RAO instructions have weaker memory ordering guarantees than conventional atomic instructions. Thus, other
instructions are not ordered with respect to RAO instructions as they are with conventional atomics.
More specifically, the memory operations from RAO instructions follow the Write Combining (WC) memory protocol.
From software's point of view, they behave similarly to non-temporal stores. Unlike non-temporal stores, RAO
instructions update a memory location, i.e., use the value in that location as an input, rather than overwrite the
current contents. Another critical difference is that with RAO, the memory location may be cached upon completion
of the instruction.
RAO instructions are not reordered with other memory accesses to the same memory location. That is, reads,
writes, and RAO instructions to the same location by the same processor will execute in program order.
However, RAO instructions may be reordered with certain memory accesses to other memory locations. In partic-
ular, RAO instructions may be reordered with writes or RAO instructions to other memory locations. This means, for
example, that if a processor executes a set of RAO instructions to a set of distinct addresses, those instructions
may appear to update memory in any order.
If a stronger ordering is required, software should use a fencing operation such as those implemented by the
LFENCE, SFENCE, and MFENCE instructions. However, note that RAO instructions are not ordered with respect to
younger LFENCE instructions since they do not load data from memory into the processor.
10.5
MEMORY TYPE
RAO instructions are restricted to operating on Write Back (WB) memory. Other memory types place restrictions on
the writing of and/or cacheability of data, which conflicts with RAO instructions' ability to cache data. Use of an RAO
instruction to access non-WB memory results in a general-protection exception (#GP).
10.6
WRITE COMBINING BEHAVIOR
RAO implementations that execute updates closer to memory require interconnect traffic between a processor and
the memory subsystem. To reduce such traffic, and increase the throughput of RAO operations, implementations
may combine multiple RAO memory operations before execution. This is similar to how multiple writes via a WC
protocol may combine before going to memory.
Implementations that combine RAO instructions take advantage of spatial locality, i.e., that a cache line contains
multiple data elements, and that separate instructions may update distinct elements in a given cache line. For
example, a first RAO instruction may update the first element in a cache line, and a second RAO instruction may
update the third element.
Implementations may have restrictions on combining operations. For example, they may only be able to combine
operations doing the same type of update (e.g., addition) and/or the same data element size.
Operations to the same cache line that are not combined must be serialized, and this could hurt performance. For
example, an operation to a given cache line may need to complete before a second operation to that cache line may
begin; otherwise, the memory system could have multiple concurrent accesses from the same processor to the
same cache line, and some implementations do not support this.
10.7
PERFORMANCE EXPECTATIONS
RAO instructions are expected to provide higher performance than conventional atomics under certain conditions.
The actual performance depends on both the implementation and the data access pattern for the memory location
(at the cache line granularity) updated with RAO instructions.
10-2
Document Number: 319433-050
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
10.7.1 Interaction Between RAO and Other Accesses
As discussed in Section 10.4, weak ordering allows RAO instructions to be reordered with respect to other memory
operations. This is a key difference from conventional atomics, which follow strong memory ordering, and can allow
a processor to execute RAO instructions with higher throughput. However, only certain reordering is allowed. If a
fence is used to enforce stronger ordering, or if a processor interleaves RAO updates with reads of the same
memory location, for example, this may result in serialized accesses, and hurt performance. If software performs
an RAO update to a memory location, and soon after reads that memory location, then the read needs to wait for
the update to complete. If the RAO is done close to memory, then the cache closest to the processor may not hold
a copy of the cache line after the RAO instruction executes, and the read may need to access a cache farther away
from the processor, or even go all the way to memory.
Mixing of RAO updates to a given memory location from one or more processors with non-RAO accesses to the
same memory location can also reduce the benefits of RAO. Implementations that perform RAO updates close to
memory can reduce data movement between a series of RAO updates to the same location. However, a non-RAO
access may cause a processor to cache the data close to itself; a subsequent RAO instruction from another
processor may require the line to be moved to a lower level of the cache hierarchy. Therefore, interleaving RAO and
non-RAO accesses to a given memory location can reduce or eliminate the data movement and/or performance
benefits of RAO.
10.7.2 Updates of Contended Data
Contended data is defined as data for which the memory system has memory accesses from multiple processors
in-flight simultaneously. That is, for contended data, the memory system is at some point in time handling at least
two accesses from different processors. Contended read-only data does not present a fundamental performance
problem, but if at least one of the contending processors attempts to write the data, e.g., perform an update on it,
the writer needs exclusive access to the data. Gaining exclusive access can be costly, in terms of latency and
traffic; in a system with caches, hardware must invalidate all other copies of the data to provide a processor exclu-
sive access.
For software performing a set of contended updates to a memory location with conventional atomic instructions,
data may “ping-pong” between processors. As each processor executes its update, it will obtain exclusive access to
the data, perform its update, and then have to send its new version of the data to the next processor wanting to
update it. The time to pass data from one processor to another, and the time that a processor takes to perform its
atomic update, limits the throughput in this scenario.
In contrast, if software uses RAO for such contended updates, and if the implementation performs the updates in
a central location such as a shared cache or at the memory controller, then this bottleneck is alleviated. In such a
scenario, each update will not have to fetch the current contents of the memory location or invalidate any other
copies of the data because the only valid copy is already at the hardware performing the update. The only funda-
mental limit to the throughput in this case is the time taken for each update. Therefore, we may expect that for
updates to contended lines, throughput is much higher with RAO. Further, reducing data movement means
reducing traffic between processors and memory. This may improve the performance of other memory accesses.
10.7.3 Updates of Uncontended Data
In contrast to contended data, uncontended data is data that is accessed by only a single processor or by multiple
processors, but far enough apart in time that at most a single memory access is executed at a time.
For uncontended data accessed by multiple processors, most of the above discussion about contended data still
applies. However, the frequency of updates is by definition lower for uncontended data. Therefore, the perfor-
mance benefits of RAO are expected to be lower in this situation.
For data accessed by only a single processor, data movement between processors is not an issue, and conventional
atomics can take advantage of the processor's caches. Performance may still be impacted by the strong ordering
of conventional atomics; memory accesses to other memory locations may not be reordered with these instruc-
tions. If software uses RAO instructions instead, the weaker ordering may provide some performance benefits.
However, if an implementation performs RAO updates closer to memory, it may not take advantage of all of the
processor's caches, and may even require removing the data from some of those caches. This could lead to an
increase in data movement, and potentially lower performance. Of course, if software is aware that only a single
processor will access the data, then it does not need to use atomic updates, but it may not always be so aware.
Document Number: 319433-050
10-3
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
10.8
EXAMPLES
10.8.1 Histogram
Histogram is a common computational pattern, including in multiprocessor programming, but achieving an efficient
parallel implementation can be tricky. In a conventional histogram computation, software sweeps over a set of
input values; it maps each input value to a histogram bin, and increments that bin.
Common multiprocessor histogram implementations partition the inputs across the processors, so each processor
works on a subset of the inputs. Straightforward implementations have each processor directly update the shared
histogram. To ensure correctness, since multiple processors may attempt updates to the same histogram bin
simultaneously, the updates must use atomics. As described above, using conventional atomics can be expensive,
especially when we have highly contended cache lines in the histogram. That may occur for small histograms or for
histograms where many inputs map to a small number of histogram bins.
A common alternative approach uses a technique called privatization, where each processor gets its own “local”
histogram; as each processor works on its subset of the inputs, it updates its local histogram. As a final “extra”
step, software must accumulate the local histograms into the globally shared histogram, a step called a reduction.
This reduction step is where processors synchronize and communicate; using it allows the computation of local
histograms to be embarrassingly parallel and require no atomics or inter-processor communication, and can often
lead to good performance. However, privatization has downsides:
• The reduction step can take a lot of time if the histogram has many bins.
• The time for a reduction is relatively constant regardless of the number of processors. As the number of
processors grows, therefore, the fraction of time spent on the reduction tends to grow.
• The local histograms require extra memory, and that memory footprint grows with the number of processors.
• The reduction is an “extra” step that complicates the software.
With RAO, software can use the simpler multiprocessor algorithm and achieve reliably good performance. The
following pseudo-code lists a RAO-based histogram implementation.
int *histogram; // “histogram” is a global histogram array
// in each processor:
double *data; // “data” is a per-processor array, holding a subset of all inputs
data = get_data(); // populate “data” values
for (size_t i = 0; i < data_size; ++i) {
int bin = map(data[i]); // map data[i] to a histogram bin
_aadd(&histogram[bin], 1); // RAO AADD instruction
}
The above code can provide good performance under various scenarios, i.e., sizes of histograms and biases in
which histogram bins are updated. RAO avoids data “ping-ponging” between processors, even under high conten-
tion. Further, the weak ordering of RAO allows a series of AADD instructions to overlap with each other in the pipe-
line, and thus provide for instruction level parallelism.
In addition to the performance benefits, the RAO code is simple and is thus easier to maintain.
While we specifically show and discuss histogram above, this computation pattern is very common, e.g., software
packet processing workloads exhibit this in how they track statistics of the packets. Other algorithms exhibiting this
pattern should similarly see benefits from RAO.
10.8.2 Interrupt/Event Handler
An interrupt/event handler, running either in a dedicated thread or preemptively in a specific processor, notifies a
set of receivers (e.g., all processors or threads in a waiting list) of the occurrence of an event by atomically setting
flags in the receivers' specific data fields. The example below shows how this may be done with RAO instructions.
10-4
Document Number: 319433-050
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
// One processor sets event bits to notify other processors:
01: void handle_event(event_t *e) {
02: uint32_t event_bits = process_event(e);
03: for (int i = 0; i < num_of_receivers; ++i) {
04:
core_t *core = receivers[i];
05:
_aor(&core->flags, event_bits); // RAO AOR instruction
06:
if (some_condition) {
07:
_aor(&core->extra_flags, event_bits); // combining of RAO could occur
08:
}
// if “extra_flags” and “flags” are in the same cache line
09:
}
10:
_mm_sfence(); // ensure event_bits are visible before leaving the handler
11: }
// In other processors:
12: if (my_core->flags & SOME_EVENT) {
13:
…… // react to the occurrence of SOME_EVENT
14:
clear_bits(&my_core->flags, SOME_EVENT);
15: }
With conventional atomics (e.g., LOCK OR), a significant portion of execution time of handle_event would be spent
accessing core->flags (line 5) and core->extra_flags (line 7). It is likely that when handle_event begins, the two
fields are in another processor's cache, e.g., if that processor updated some bits in the fields. Therefore, the data
would need to migrate to the cache of the processor executing handle_event.
In contrast, for the above code example, for RAO implementations that perform updates close to memory, the RAO
AOR instruction should reduce data movement of core->flags and core->extra_flags and thus result in a lower
execution latency. Further, when other processors later access these fields (lines 12-15), they will also benefit from
a lower latency due to reduced data movement, since they may get the data from a more central location.
Also note that since the order of notifications does not matter in this case, the function further takes advantage of
RAO's weak ordering, allowing multiple RAO AOR instructions to be executed concurrently. It does, however,
include a memory fence at the end (line 10), to ensure that all updates are visible to all processors before leaving
the handler.
Document Number: 319433-050
10-5
REMOTE ATOMIC OPERATIONS IN INTEL ARCHITECTURE
10-6
Document Number: 319433-050
TOTAL STORAGE ENCRYPTION IN INTEL ARCHITECTURE
CHAPTER 11
TOTAL STORAGE ENCRYPTION IN INTEL ARCHITECTURE
11.1
INTRODUCTION
Total Storage Encryption (TSE) is an architecture that allows encryption of storage at high speed. TSE provides the
following capabilities:
• Protection (confidentiality) of data at rest in storage.
• NIST Standard AES-XTS Encryption.
• A mechanism for software to configure hardware keys (which are not software visible) or software keys.
• A consistent key interface to the crypto engine.
11.1.1 Key Programming Overview
Keys for TSE can either be programmed directly in plain text or through wrapped Binary Large Objects (BLOBs).
• Direct programming: Software programs keys after reset to the TSE engine using a structure in memory. Keys
may be exposed in memory.
• Wrapped BLOB programming: Wrapped-key BLOBs are generated once at provisioning time, persist across
boots, and are used directly to program the TSE engine without unwrapping/recovering keys in software.
11.1.1.1 Key Wrapping Support: PBNDKB
Platform Bind Key BLOB (PBNDKB) allows software to wrap secret information with a platform-specific wrapping
key and bind it to the TSE engine.
11.1.2 Unwrapping and Hardware Key Programming Support: PCONFIG
The PCONFIG instruction allows software to program keys to the TSE engine either directly from memory or using
PBNDKB-generated wrapped BLOBs.
The PCONFIG instruction is also used to program the TME-MK engine. For additional details on the PCONFIG
instruction, see Chapter 2 of this document.
11.2
ENUMERATION
CPUID enumerates the existence of the IA32_TSE_CAPABILITY MSR and the PBNDKB instruction.
The IA32_TSE_CAPABILITY MSR enumerates supported cryptographic algorithms and keys.
11.2.1 CPUID Detection
If CPUID.(EAX=07H, ECX=1):EBX.PBNDKB[bit 1] = 1, the processor supports the IA32_TSE_CAPABILITY MSR and
the PBNDKB instruction.
11.2.1.1 PCONFIG CPUID Leaf Extended to Support Total Storage Encryption
TSE is assigned a PCONFIG target identifier. The current PCONFIG target identifiers are as follows:
•
0: Invalid Target ID
•
1: TME-MK
Document Number: 319433-050
11-1
TOTAL STORAGE ENCRYPTION IN INTEL ARCHITECTURE
•
2: TSE
If TSE is supported on the platform, CPUID.PCONFIG_LEAF will enumerate TSE as a supported target in sub-leaf 0,
ECX=TSE:
• TSE_KEY_PROGRAM leaf is available when TSE is enumerated by PCONFIG as a target.
• TSE_KEY_PROGRAM_WRAPPED is available when TSE is enumerated by PCONFIG as a target.
11.2.2 Total Storage Encryption Capability MSR
The TSE_CAPABILITY MSR (9F1H) enumerates the supported capabilities of TSE. It has the fields shown in
Table 11-1.
Table 11-1. TSE Capability MSR Fields
Bit
Description
15:0
Supported encryption algorithms (see below).
23:16
TSE Engine Key Sources Supported.
35:24
Reserved.
50:36
TSE_MAX_KEYS (Indicates the maximum number of keys that are available).
63:51
Reserved.
Bits 15:0 enumerate, as a bitmap, the encryption algorithms that are supported. As of this writing, the only
supported algorithm is 256-bit AES-XTS, which is enumerated by setting bit 0.
11.3
VMX SUPPORT
11.3.1 Changes to VMCS Fields
A new execution control called “enable PBNDKB” is added to support TSE in bit 9 of the tertiary processor-based
execution controls field of the VMCS. If this control is zero, then any execution of the PBNDKB instruction causes an
invalid-opcode exception (#UD).
11.3.2 Changes to VMX Capability MSRs
Support for “enabled PBNDKB” is indicated by bit 9 of the IA32_VMX_PROCBASED_CTLS3 MSR (index 492H).
11.3.3 Changes to VM Entry
If bit 9 is clear in the IA32_VMX_PROCBASED_CTLS3 MSR, then VM entry fails if “enable PBNDKB” and the
“activate tertiary controls” primary processor-based VM-execution control are both 1.
11.4
INSTRUCTION SET
See Chapter 2 for details on the PBNDKB instruction, as well as information on updates to the PCONFIG instruction.
11-2
Document Number: 319433-050