Apparatus and method for security platform monitoring techniques

Abstract

An apparatus and method for secure platform monitoring. For example, one embodiment of a processor includes: a plurality of processing cores to execute instructions in different execution contexts, the different execution contexts including a trusted execution context associated with a trusted execution environment; telemetry aggregation circuitry to aggregate telemetry data associated with one or more of the different execution contexts; a filter to prevent the telemetry data associated with the trusted execution context from being aggregated by the telemetry aggregation circuit; and an interface for transmitting the telemetry data aggregated by the telemetry aggregation circuit to an external agent.

Description

background Technical Field

[0001] The present invention generally relates to the field of computer processors. More specifically, the present invention relates to an apparatus and method for secure platform monitoring technology. Background Art

[0002] Core out-of-band (OOB) telemetry is a platform monitoring mechanism in which a core periodically transmits telemetry data to a management unit (e.g., in a shared or "uncore" area of ​​the processor), which accumulates the telemetry data and potentially transmits the accumulated telemetry data to an external management agent. For example, the OOB manageability service microcontroller (OOB-MSM) is a shared / uncore unit that collects telemetry data from the core and reports the telemetry data out to an external management agent (such as a baseboard management controller (BMC)). Telemetry data includes, but is not limited to, information about core instruction execution, environmental data (temperature, frequency, voltage), and cache operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

[0004] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

[0005] Figure 1 illustrates an example computer system architecture;

[0006] Figure 2 The diagram shows a processor including multiple cores;

[0007] FIG3(A) illustrates the various stages of a processing pipeline;

[0008] FIG3(B) illustrates details of one embodiment of a core;

[0009] Figure 4 FIG. 1 illustrates an execution circuit according to an embodiment;

[0010] Figure 5 One embodiment of a graphical register architecture is shown;

[0011] Figure 6 An example of the illustrated instruction format;

[0012] Figure 7illustrates an addressing technique according to one embodiment;

[0013] Figure 8 An embodiment of an instruction prefix is ​​shown;

[0014] Figure 9(A)-Figure 9(D) An embodiment illustrating how the R, X, and B fields of a prefix are used;

[0015] Figure 10(A)-Figure 10(B) An example of a second instruction prefix is ​​shown;

[0016] Fig.11 illustrates the payload bytes of one embodiment of an instruction prefix;

[0017] Fig.12 Diagram the implementation of instruction conversion and binary translation;

[0018] Fig.13 illustrates an architecture according to an embodiment of the present invention;

[0019] Fig.14 illustrates the interaction between the core,presentation circuitry and the telemetry aggregator according to an embodiment of the present invention;

[0020] Figure 15A-Figure 15C illustrates a series of transactions according to an embodiment of the present invention; and

[0021] Fig.16 A method according to an embodiment of the present invention is illustrated. DETAILED DESCRIPTION

[0022] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the embodiments of the invention described below. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the embodiments of the invention.

[0023] Exemplary Computer Architecture

[0024] Exemplary computer architectures are described in detail below. Other system designs and configurations for laptops, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and a large number of various other electronic devices known in the art are also appropriate. In a word, various systems or electronic devices that can include processors disclosed herein and / or other execution logics are generally appropriate.

[0025] Figure 1 An embodiment of an exemplary system is illustrated. Multiprocessor system 100 is a point-to-point interconnect system and includes a plurality of processors, including a first processor 170 and a second processor 180 coupled via a point-to-point interconnect 150. In some embodiments, first processor 170 and second processor 180 are homogeneous. In some embodiments, first processor 170 and second processor 180 are heterogeneous.

[0026] Processors 170 and 180 are shown as including integrated memory controller (IMC) unit circuits 172 and 182, respectively. Processor 170 also includes point-to-point (PP) interfaces 176 and 178 as part of its interconnect controller unit; similarly, second processor 180 includes PP interfaces 186 and 188. Processors 170, 180 can exchange information via PP interconnect 150 using point-to-point (PP) interface circuits 178, 188. IMCs 172 and 182 couple processors 170, 180 to respective memories, namely memory 132 and memory 134, which can be part of the main memory locally attached to the respective processors.

[0027] Processors 170, 180 may each utilize point-to-point interface circuits 176, 194, 186, 198 to exchange information with chipset 190 via respective PP interconnects 152, 154. Chipset 190 may optionally exchange information with coprocessor 138 via high-performance interface 192. In some embodiments, coprocessor 138 is a special-purpose processor, such as a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and the like.

[0028] A shared cache (not shown) may be included in either processor 170, 180, or external to both processors but connected to these processors via the PP interconnect, so that if a processor is placed in a low power mode, local cache information of either or both processors may also be stored in the shared cache.

[0029] Chipset 190 may be coupled to first interconnect 116 via interface 196. In some embodiments, first interconnect 116 may be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I / O interconnect. In some embodiments, one of these interconnects is coupled to a power control unit (PCU) 117, which may include circuitry, software, and / or firmware to perform power management operations with respect to processors 170, 180, and / or coprocessor 138. PCU 117 provides control information to the voltage regulator so that the voltage regulator generates an appropriate regulated voltage. PCU 117 also provides control information to control the generated operating voltage. In various embodiments, PCU 117 may include various power management logic units (circuits) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0030] PCU 117 is illustrated as existing as logic separate from processor 170 and / or processor 180. In other cases, PCU 117 may execute on a given one or more cores of a core (not shown) of processor 170 or 180. In some cases, PCU 117 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other embodiments, the power management operations to be performed by PCU 117 may be implemented external to the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In still other embodiments, the power management operations to be performed by PCU 117 may be implemented within BIOS or other system software.

[0031] Various I / O devices 114 and an interconnect (bus) bridge 118 may be coupled to the first interconnect 116, and the interconnect (bus) bridge 118 couples the first interconnect 116 to the second interconnect 120. In some embodiments, one or more additional processors 115 are coupled to the first interconnect 116, such as a coprocessor, a high throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some embodiments, the second interconnect 120 may be a low pin count (LPC) interconnect. Various devices may be coupled to the second interconnect 120, including, for example, a keyboard and / or mouse 122, a communication device 127, and a storage unit circuit 128. The storage unit circuit 128 may be a disk drive or other mass storage device, which may include instructions / code and data 130 in some embodiments. In addition, an audio I / O 124 may be coupled to the second interconnect 120. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 100 may implement a multi-drop interconnect or other such architecture rather than a point-to-point architecture.

[0032] Exemplary Core Architectures, Processors, and Computer Architectures

[0033] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores, for general-purpose computing purposes; 2) high-performance general-purpose out-of-order cores, for general-purpose computing purposes; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU, including one or more general-purpose in-order cores for general-purpose computing purposes and / or one or more general-purpose out-of-order cores for general-purpose computing purposes; and 2) a coprocessor, including one or more special-purpose cores mainly for graphics and / or scientific (throughput) purposes. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies in the same package as the CPU; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip, which may include the above-described coprocessors and additional functionality on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s). An exemplary core architecture is described next, followed by a description of exemplary processor and computer architectures.

[0034] Figure 2 A block diagram of an embodiment of an example processor 200 is illustrated, which may have more than one core, may have an integrated memory controller, and may have an integrated graphics device. The solid-lined box illustrates the processor 200 as having a single core 202(A), a system agent 210, and a set of one or more interconnected controller unit circuits 216, while the optionally added dashed-lined box illustrates an alternative processor 200 as having multiple cores 202(A)-(N), a set of one or more integrated memory control unit circuits 214 in the system agent unit circuit 210, dedicated logic 208, and a set of one or more interconnected controller unit circuits 216. Note that the processor 200 may be Figure 1 One of the processors 170 or 180 or the coprocessors 138 or 115.

[0035] Thus, different implementations of processor 200 may include: 1) a CPU, where dedicated logic 208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 202(A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 202(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 202(A)-(N) are a large number of general purpose in-order cores. Thus, processor 200 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit circuit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, and the like. The processor may be implemented on one or more chips. Processor 200 may be part of one or more substrates and / or may be implemented on one or more substrates using any of a variety of process technologies, such as BiCMOS, CMOS, or NMOS.

[0036] The memory hierarchy includes one or more levels of cache unit circuitry 204(A)-(N) within the cores 202(A)-(N), a set of one or more shared cache unit circuitry 206, and external memory (not shown) coupled to the set of integrated memory controller unit circuitry 214. The set of one or more shared cache unit circuitry 206 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other level caches, such as last level cache (LLC), and / or combinations thereof. While in some embodiments a ring-based interconnect network circuitry 212 interconnects the dedicated logic 208 (e.g., integrated graphics logic), the set of shared cache unit circuitry 206, and the system agent unit circuitry 210, alternative embodiments interconnect these units using any number of well-known techniques. In some embodiments, coherency is maintained between one or more circuits in the shared cache unit circuitry 206 and the cores 202(A)-(N).

[0037] In some embodiments, one or more of the cores 202(A)-(N) have multi-threading capabilities. The system agent unit circuit 210 includes those components that coordinate and operate the cores 202(A)-(N). The system agent unit circuit 210 may include, for example, a power control unit (PCU) circuit and / or a display unit circuit (not shown). The PCU may be (or may include) the logic and components required to adjust the power state of the cores 202(A)-(N) and / or the dedicated logic 208 (e.g., integrated graphics logic). The display unit circuit is used to drive one or more externally connected displays.

[0038] The cores 202(A)-(N) may be homogeneous or heterogeneous with respect to the architectural instruction set; that is, two or more of the cores 202(A)-(N) may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of the instruction set or may be capable of executing a different ISA.

[0039] Exemplary Core Architecture

[0040] In-order and out-of-order core block diagram

[0041] The block diagram of FIG. 3(A) illustrates both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline according to an embodiment of the present invention. The block diagram of FIG. 3(B) illustrates both an exemplary embodiment of an in-order architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core according to an embodiment of the present invention. The solid-line boxes in FIG. 3(A)-(B) illustrate the in-order pipeline and the in-order core, while the optionally added dashed-line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0042] In FIG. 3(A), the processor pipeline 300 includes a fetch stage 302, an optional length decode stage 304, a decode stage 306, an optional allocation stage 308, an optional rename stage 310, a dispatch (also called dispatch or issue) stage 312, an optional register read / memory read stage 314, an execute stage 316, a write back / memory write stage 318, an optional exception handling stage 322, and an optional commit stage 324. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 302, one or more instructions are fetched from the instruction memory, during the decode stage 306, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In one embodiment, the decode stage 306 and the register read / memory read stage 314 may be combined into one pipeline stage. In one embodiment, during the execution stage 316, decoded instructions may be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0043] As an example, the exemplary register renaming, out-of-order issue / execution core architecture may implement the pipeline 300 in the following manner: 1) instruction fetch 338 performs fetch and length decode stages 302 and 304; 2) decode unit circuit 340 performs decode stage 306; 3) rename / allocator unit circuit 352 performs allocation stage 308 and rename stage 310; 4) (one or more) scheduler unit circuit 356 performs scheduling stage 312; 5) (one or more) physical register file unit circuit 358 and memory unit circuit 370 perform register read / memory read stage 314; execution cluster 360 performs execution stage 316; 6) memory unit circuit 370 and (one or more) physical register file unit circuit 358 perform write back / memory write stage 318; 7) various units (unit circuits) may be involved in the exception handling stage 322; and 8) retirement unit circuit 354 and (one or more) physical register file unit circuit 358 perform commit stage 324.

[0044] 3(B) shows that the processor core 390 includes a front end unit circuit 330 coupled to an execution engine unit circuit 350, and both are coupled to a memory unit circuit 370. The core 390 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 390 can be a special-purpose core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0045] The front end unit circuit 330 may include a branch prediction unit circuit 332, which is coupled to an instruction cache unit circuit 334, which is coupled to an instruction translation lookaside buffer (TLB) 336, which is coupled to an instruction fetch unit circuit 338, which is coupled to a decode unit circuit 340. In one embodiment, the instruction cache unit circuit 334 is included in the memory unit circuit 370 instead of the front end unit circuit 330. The decode unit circuit 340 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode unit circuit 340 may also include an address generation unit (AGU, not shown). In one embodiment, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode unit circuit 340 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read only memory (ROM), and the like. In one embodiment, the core 390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode unit circuit 340 or otherwise within the front end unit circuit 330). In one embodiment, the decode unit circuit 340 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during the decode or other stages of the processor pipeline 300. The decode unit circuit 340 may be coupled to the rename / allocator unit circuit 352 in the execution engine unit circuit 350.

[0046] The execution engine circuitry 350 includes a rename / allocator unit circuitry 352 coupled to a retirement unit circuitry 354 and a set of one or more scheduler circuits 356. The scheduler circuitry 356 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some embodiments, the scheduler circuitry 356 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuitry 356 is coupled to a physical register file (s) circuitry 358. Each of the physical register file (s) circuitry 358 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., instruction pointers, i.e., the address of the next instruction to be executed), and the like. In one embodiment, the physical register file unit circuitry 358 includes vector register unit circuitry, write mask register unit circuitry, and scalar register unit circuitry. These register units may provide architectural vector registers, vector mask registers, general purpose registers, and the like. The physical register file unit circuitry 358 is overlapped by a retirement unit circuitry 354 (also referred to as a retirement queue) to demonstrate various ways in which register renaming and out-of-order execution may be implemented (e.g., utilizing reorder buffers (ROBs) and retirement register files (ROBs); utilizing future stacks (ROBs), history buffers (ROBs), and retirement register files (ROBs); utilizing register maps and register pools; and the like). The retirement unit circuitry 354 and the physical register file circuitry 358 are coupled to execution clusters (one or more) 360. The execution clusters (one or more) 360 include a set of one or more execution unit circuits 362 and a set of one or more memory access circuits 364. Execution unit circuitry 362 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other embodiments may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 356, physical register file unit circuit(s) 358, and execution cluster(s) 360 are shown as potentially multiple because some embodiments create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with its own scheduler circuit(s), physical register file unit circuit(s), and / or execution cluster—and in the case of a separate memory access pipeline, some embodiments implemented only the execution cluster of that pipeline has memory access unit circuit(s) 364). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0047] In some embodiments, the execution engine unit circuit 350 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0048] A set of memory access circuits 364 are coupled to the memory cell circuit 370, which includes a data TLB unit circuit 372, which is coupled to a data cache circuit 374, which is coupled to a level 2 (L2) cache circuit 376. In an exemplary embodiment, the memory access unit circuit 364 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 372 in the memory cell circuit 370. The instruction cache circuit 334 is further coupled to the level 2 (L2) cache unit circuit 376 in the memory cell circuit 370. In one embodiment, the instruction cache 334 and the data cache 374 are combined into a single instruction and data cache in the L2 cache unit circuit 376, a level 3 (L3) cache unit circuit (not shown), and / or a main memory (not shown). The L2 cache unit circuit 376 is coupled to one or more other levels of cache and ultimately coupled to the main memory.

[0049] Core 390 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set; the ARM instruction set (with optional additional extensions, such as NEON)) that include the instruction(s) described herein. In one embodiment, core 390 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using packed data.

[0050] Exemplary Execution Unit Circuit(s)

[0051] Figure 4 An embodiment of (one or more) execution unit circuits is illustrated, such as (one or more) execution unit circuits 362 of FIG. 3(B). As shown, (one or more) execution unit circuits 362 may include one or more ALU circuits 401, vector / SIMD unit circuits 403, load / store unit circuits 405, and / or branch / jump unit circuits 407. ALU circuits 401 perform integer arithmetic and / or Boolean operations. Vector / SIMD unit circuits 403 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store unit circuits 405 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store unit circuits 405 may also generate addresses. Branch / jump unit circuits 407 cause branches or jumps to a certain memory address depending on the instruction. Floating-point unit (FPU) circuits 409 perform floating-point arithmetic. The width of execution unit circuitry 362 varies depending on the embodiment and may range from 16 bits to 1024 bits. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0052] Exemplary Register Architecture

[0053] Figure 5 5 is a block diagram of a register architecture 500 according to some embodiments. As shown, there is a vector / SIMD register 510, whose width varies from 128 bits to 1024 bits. In some embodiments, the vector / SIMD register 510 is physically 512 bits, and only some low-order bits are used depending on the mapping. For example, in some embodiments, the vector / SIMD register 510 is a 512-bit ZMM register: the low-order 256 bits are used for the YMM register, and the low-order 128 bits are used for the XMM register. Therefore, there is an overlay of registers. In some embodiments, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either maintained as the same as before the instruction, or are zeroed, depending on the embodiment.

[0054] In some embodiments, the register architecture 500 includes write mask / predicate registers 515. For example, in some embodiments, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate registers 515 can allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some embodiments, each data element position in a given write mask / predicate register 515 corresponds to a data element position in the destination. In other embodiments, the write mask / predicate registers 515 are scalable and consist of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

[0055] The register architecture 500 includes a plurality of general purpose registers 525. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some embodiments, these registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0056] In some embodiments, register architecture 500 includes scalar floating point registers 545, which are used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using the x87 instruction set extension, or as MMX registers to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between MMX and XMM registers.

[0057] One or more flag registers 540 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 540 can store conditional code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some embodiments, one or more flag registers 540 are referred to as program status and control registers.

[0058] Segment registers 520 contain segment points for accessing memory. In some embodiments, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0059] Machine-specific registers (MSRs) 535 control and report processor performance. Most MSRs 535 handle system-related functions and are not accessible to applications. Machine check registers 560 consist of control, status, and error reporting MSRs used to detect and report hardware errors.

[0060] One or more instruction pointer registers 530 store instruction pointer values. Control register(s) 555 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processor 170, 180, 138, 115, and / or 200) and the characteristics of the task currently being executed. Debug registers 550 control and allow monitoring of debug operations of a processor or core.

[0061] Memory management registers 565 specify the location of data structures used in protected mode memory management. These registers may include the GDTR, IDTR, task register, and LDTR registers.

[0062] Alternative embodiments of the present invention may use wider or narrower registers. In addition, alternative embodiments of the present invention may use more, fewer or different register files and registers.

[0063] Instruction Set

[0064] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because there are fewer included fields) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, an exemplary ADD instruction has a specific opcode and instruction format, which includes an opcode field to specify the opcode and an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field to select the specific operand.

[0065] Example instruction format

[0066] The embodiments of the (one or more) instructions described herein may be implemented in different formats. In addition, exemplary systems, architectures, and pipelines are described in detail below. Embodiments of the (one or more) instructions may be executed on these systems, architectures, and pipelines, but are not limited to those described in detail.

[0067] Figure 6 An embodiment of an instruction format is illustrated. As shown, an instruction may include multiple components, including but not limited to one or more fields for the following items: one or more prefixes 601, opcode 603, addressing information 605 (e.g., register identifier, memory addressing information, etc.), displacement value 607, and / or immediate value 609. Note that some instructions utilize some or all fields of the format, while other instructions may only use the opcode 603 field. In some embodiments, the illustrated order is the order in which these fields are to be encoded, however, it should be understood that in other embodiments, these fields may be encoded in another order, combined, etc.

[0068] (One or more) prefix fields 601 modify the instruction when used. In some embodiments, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operation objects (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0069] The opcode field 603 is used to at least partially define the operation to be performed when the instruction is decoded. In some embodiments, the length of the primary opcode encoded in the opcode field 603 is 1, 2 or 3 bytes. In other embodiments, the primary opcode can be other lengths. The additional 3-bit opcode field is sometimes encoded in another field.

[0070] The addressing field 605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Figure 7605. An embodiment of the addressing field 605 is illustrated. In this illustration, an optional MOD R / M byte 702 and an optional Scale, Index, Base (SIB) byte 704 are shown. The MOD R / M byte 702 and SIB byte 704 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that each of these fields is optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 702 includes a MOD field 742, a register field 744, and an R / M field 746.

[0071] The content of MOD field 742 distinguishes between memory access and non-memory access modes. In some embodiments, when MOD field 742 has a value of b11, register direct addressing mode is utilized, otherwise register indirect addressing is used.

[0072] Register field 744 may encode a destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The contents of register index field 744 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some embodiments, register field 744 is supplemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing.

[0073] R / M field 746 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some embodiments, R / M field 746 may be combined with MOD field 742 to specify an addressing mode.

[0074] SIB byte 704 includes a scaling field 752, an index field 754, and a base address field 756 for address generation. Scaling field 752 indicates a scaling factor. Index field 754 specifies the index register to be used. In some embodiments, index field 754 is complemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing. Base address field 756 specifies the base address register to be used. In some embodiments, base address field 756 is complemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing. In practice, the contents of scaling field 752 allow the contents of index field 754 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0075] Some addressing forms use displacement values ​​to generate memory addresses. For example,缩放 * index + base + displacement, index * scaling + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. to generate a memory address. The displacement can be a value of 1 byte, 2 bytes, 4 bytes, etc. In some embodiments, the displacement field 607 provides this value. In addition, in some embodiments, the use of a displacement factor is encoded in the MOD field of the addressing field 605, which indicates a compressed displacement scheme, for which the displacement value is calculated by multiplying disp8 with a scaling factor N determined based on the vector length, the value of the b bit, and the input element size of the instruction. The displacement value is stored in the displacement field 607.

[0076] In some embodiments, the immediate value field 609 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0077] Figure 8 An embodiment of a first prefix 601(A) is illustrated. In some embodiments, the first prefix 601(A) is an embodiment of a REX prefix. Instructions using this prefix may specify general purpose registers, 64-bit packed data registers (e.g., single instruction multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0078] Instructions using the first prefix 601(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the reg field 744 and the R / M field 746 of the MOD R / M byte 702; 2) using the MOD R / M byte 702 with the SIB byte 704, including using the reg field 744 as well as the base field 756 and the index field 754; or 3) using the register field of the opcode.

[0079] In the first prefix 601 (A), bit positions 7:4 are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0080] Note that adding another bit allows for 16 (2 4 ) registers, while the separate MOD R / M reg field 744 and the R / M field 746 of MOD R / M can only address 8 registers each.

[0081] In the first prefix 601(A), bit position 2 (R) may be an extension of the MOD R / M reg field 744 and may be used to modify the MOD R / M reg field 744 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 702 specifies other registers or defines an extended opcode, R is ignored.

[0082] Bit position 1 (X) X bits may modify the SIB byte index field 754 .

[0083] Bit position B (B) B may modify the base address in the R / M field 746 or SIB byte base address field 756 of MOD R / M; or it may modify the opcode register field used to access a general register (eg, general register 525).

[0084] 9(A)-(D) illustrate embodiments of how the R, X, and B fields of the first prefix 601(A) are used. FIG. 9(A) illustrates that when the SIB byte 704 is not used for memory addressing, the R and B from the first prefix 601(A) are used to extend the reg field 744 and the R / M field 746 of the MOD R / M byte 702. FIG. 9(B) illustrates that when the SIB byte 704 is not used, the R and B from the first prefix 601(A) are used to extend the reg field 744 and the R / M field 746 of the MOD R / M byte 702 (register-register addressing). FIG. 9(C) illustrates that when the SIB byte 704 is used for memory addressing, the R, X, and B from the first prefix 601(A) are used to extend the reg field 744 and the index field 754 and the base address field 756 of the MOD R / M byte 702. FIG. 9(D) illustrates that when a register is encoded in the opcode 603 , the B from the first prefix 601 (A) is used to extend the reg field 744 of the MOD R / M byte 702 .

[0085] Figure 10 (A)-(B) illustrates an embodiment of the second prefix 601 (B). In some embodiments, the second prefix 601 (B) is an embodiment of a VEX prefix. The second prefix 601 (B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD registers 510) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 601 (B) provides a syntax for three operands (or more). For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the second prefix 601 (B) enables the operands to perform non-destructive operations, such as A=B+C.

[0086] In some embodiments, the second prefix 601(B) has two forms: a two-byte form and a three-byte form. The two-byte second prefix 601(B) is mainly used for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix 601(B) provides a compact replacement for 3-byte opcode instructions and the first prefix 601(A).

[0087] Figure 10 (A) illustrates an embodiment of the two-byte form of the second prefix 601 (B). In one example, the format field 1001 (byte 0 1003) contains the value C5H. In one example, byte 1 1005 includes an "R" value in bit [7]. This value is the complement of the same value of the first prefix 601 (A). Bit [2] is used to specify the length (L) of the vector (wherein the value of 0 is a scalar or 128-bit vector, and the value of 1 is a 256-bit vector). Bit [1:0] provides an operation code extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0088] Instructions using this prefix may use the R / M field 746 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0089] Instructions using this prefix may use the reg field 744 of MOD R / M to encode either a destination register operand or a source register operand, treated as an opcode extension and not used to encode any instruction operand.

[0090] For instruction syntax supporting four operands, vvvv, the R / M field 746 of MOD R / M, and the reg field 744 of MOD R / M encode three of the four operands. Bits [7:4] of the immediate 609 are then used to encode the third source register operand.

[0091] FIG. 10 (B) illustrates an embodiment of a three-byte form of the second prefix 601 (B). In one example, the format field 1011 (byte 0 1013) contains the value C4H. Byte 1 1015 includes "R", "X" and "B" in bit [7:5], which are the complements of these values ​​of the first prefix 601 (A). Bit [4:0] (shown as mmmm) of byte 1 1015 includes the content of encoding one or more implicit leading opcode bytes as needed. For example, 00001 means 0FH leading opcode, 00010 means 0F38H leading opcode, 00011 means 0F3AH leading opcode, and so on.

[0092] The use of bit [7] of byte 2 1017 is similar to W of the first prefix 601 (A), including helping to determine the size of the operand that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form, valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value, such as 1111b.

[0093] Instructions using this prefix may use the R / M field 746 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0094] Instructions using this prefix may use the reg field 744 of MOD R / M to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0095] For instruction syntax supporting four operands, vvvv, the R / M field 746 of MOD R / M, and the reg field 744 of MOD R / M encode three of the four operands. Bits [7:4] of the immediate 609 are then used to encode the third source register operand.

[0096] Fig.11An embodiment of a third prefix 601(C) is illustrated. In some embodiments, the third prefix 601(C) is an embodiment of an EVEX prefix. The third prefix 601(C) is a four-byte prefix.

[0097] The third prefix 601 (C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some embodiments, write masks / operation masks are used (see the discussion of registers in previous figures, e.g., Figure 5 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions whose source / destination operands are operation mask registers and treat the contents of the operation mask register as a single value are encoded using the second prefix 601 (B).

[0098] The third prefix 601(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0099] The first byte of the third prefix 601 (C) is the format field 1111, which in one example has a value of 62 H. The subsequent bytes are referred to as payload bytes 1115-1119, and together form a 24-bit value of P[23:0], providing specific capabilities in the form of one or more fields (described in detail herein).

[0100] In some embodiments, P[1:0] of payload byte 1119 is the same as the two lower mm bits. In some embodiments, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and the reg field 744 of MOD R / M. P[6] can also provide access to the upper 16 vector registers when SIB type addressing is not required. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with the MOD R / M register field 744 and the R / M field 746 of MOD R / M, allows access to the next set of 8 registers beyond the lower 8 registers. P[9:8] provides opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

[10] is a fixed value of 1 in some embodiments. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0101] P

[15] is similar to W of the first prefix 601 (A) and the second prefix 611 (B), and can be used as an opcode extension bit or an operand size increase.

[0102] P[18:16] specifies the index of a register in the operation mask (write mask) register (e.g., write mask / predicate register 515). In one embodiment of the invention, the particular value aaa=000 has special behavior, implying that no operation mask is used for this particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in another embodiment, the old value of each element of the destination is retained (if the corresponding mask bit has a value of 0). In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic and enhanced operations); in one embodiment, the elements of the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length (i.e., the span of elements modified, from first to last) of the operation being performed; however, the elements modified do not have to be contiguous. Thus, the operation mask field enables a subset of vector operations, including loads, stores, arithmetic, logical, etc. Although in the described embodiment of the invention, the contents of the operation mask field select which of several operation mask registers contains the operation mask to be used (thus the contents of the operation mask field indirectly identify the masking to be performed), alternative embodiments alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0103] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can utilize P

[19] to access the upper 16 vector registers. P

[20] encodes various features that vary in different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge-write masking (e.g., when set to 0) or support for zeroing and merge-write masking (e.g., when set to 1).

[0104] The following table details an exemplary embodiment of the encoding of registers in instructions using the third prefix 601 (C). Table 1: 32-register support in 64-bit mode Table 2: Encoding register specifiers in 32-bit mode Table 3: Operation Mask Register Specifier Encoding

[0105] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the present application, a processing system includes any system having a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0106] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0107] The embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation approaches. Embodiments of the present invention may be implemented as a computer program or program code, executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0108] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represent various logic within a processor, which, when read by a machine, causes the machine to fabricate logic for performing the techniques described herein. These representations, known as "IP cores," may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a fabrication machine that actually fabricates the logic or processor.

[0109] These machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of items manufactured or formed by a machine or device, including storage media such as: hard disks, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM)), magnetic cards or optical cards, or any other type of medium suitable for storing electronic instructions.

[0110] Therefore, embodiments of the present invention also include non-transitory tangible machine-readable media that contain instructions or design data that define the structures, circuits, devices, processors and / or system features described herein, such as hardware description languages ​​(HDL). Such embodiments may also be referred to as program products.

[0111] Emulation (including binary translation, code deformation, etc.)

[0112] In some cases, the instruction converter can be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0113] Fig.12A block diagram illustrating the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to some implementations. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Fig.12 A program in a high-level language 1202 is shown to be compiled using a first ISA compiler 1204 to generate first ISA binary code 1206 that can be natively executed by a processor 1216 having at least one first ISA instruction set core. The processor 1216 having at least one first ISA instruction set core represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the instruction set of the first ISA instruction set core or (2) executing a program in a first ISA instruction set core in a manner compatible with or otherwise processing the instruction set of the processor. The first ISA compiler 1204 represents a compiler operable to generate first ISA binary code 1206 (e.g., object code) that can be executed on a processor 1216 having at least one first ISA instruction set core with or without additional linking processing.

[0114] Similarly, Fig.12 It is shown that a program in a high-level language 1202 can be compiled using an alternative instruction set compiler 1208 to generate an alternative instruction set binary code 1210, which can be executed natively by a processor 1214 without a first ISA core. An instruction converter 1212 is used to convert the first ISA binary code 1206 into code that can be executed natively by a processor 1214 without a first ISA instruction set core. This converted code may not be the same as the alternative instruction set binary code 1210, because an instruction converter that can do this is difficult to make; however, the converted code will implement the overall operation and be composed of instructions from the alternative instruction set. Thus, the instruction converter 1212 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device that does not have a first ISA instruction set processor or core to execute the first ISA binary code 1206 through simulation, emulation, or any other process. Device and method for secure platform monitoring technology

[0115] Core out-of-band (OOB) telemetry is a platform monitoring mechanism in which a core periodically transmits telemetry data to a management unit (e.g., within a shared or "uncore" area of ​​the processor), which accumulates the telemetry data and potentially transmits the accumulated telemetry data to an external management agent. For example, the OOB Manageability Services Microcontroller (OOB-MSM) is a shared / uncore unit that collects telemetry data from the core and reports the telemetry data out to an external management agent, such as a baseboard management controller (BMC). The telemetry data contains information (e.g., counter values) related to core instruction execution, environmental data (temperature, frequency, voltage), and cache operation.

[0116] Given the need to protect the trusted execution environment (TEE) from side-channel leaks through OOB telemetry data processing, there is a conflict between the requirement for confidentiality in the TEE and the need for telemetry data collection for platform monitoring.

[0117] To resolve these conflicting requirements, embodiments of the present invention control the manner in which telemetry data collected from a trusted execution environment is reported outward from the processor. In a particular embodiment, trusted execution awareness extends from the core to a shared or "uncore" area of ​​the processor. As used herein, the "uncore" area includes any circuitry external to the processing core (e.g., CPU core), including, by way of example, but not limited to, on-chip interconnects, memory controllers, shared caches (e.g., L3 caches), I / O interfaces, graphics processing circuits, and SoC power / performance management controllers.

[0118] In one implementation, a security policy is defined that allows all data, no telemetry data, or some telemetry data during trusted execution, thereby providing a balance between the need for telemetry data and the security requirements of the trusted execution environment type / instance. In one implementation, the security policy supports a telemetry class layer to provide an indication of telemetry exposure. For example, a security policy may be specified in a contract between a cloud service provider (CSP) and a customer that indicates telemetry exposure from a TEE (or each type of TEE), including the ability to configure a multi-layer subset of SoC telemetry. Each telemetry subset may be runtime configurable via a signed license that defines security policies for different in-band and out-of-band access. The license may be created by the CSP based on a contract between the CSP and the customer. In an implementation where a single SoC supports multiple layers of telemetry, the most restrictive security policy is applied. In some embodiments, telemetry exposure is defined at least in part based on the ability to add a configurable signal-to-noise (SNR) via a license described herein. Telemetry from the Trusted Execution Environment

[0119] Fig.13 An example SoC 1300 within a platform 1390 is illustrated, wherein telemetry metrics are generated / collected by platform monitoring (PM) agents 1311-1312 within cores 1301-1302, respectively, and transmitted to a telemetry aggregator via an out-of-band or in-band channel. In one implementation, the telemetry data is transmitted to an out-of-band management service module (OOB-MSM) 1321 configured in a non-core / shared area 1320 of the SoC 1300, which aggregates the telemetry data provided by the platform monitoring agents 1311-1312, and potentially aggregates one or more other units 1322 within the non-core / shared area 1320. In this implementation, a filter 1341 operating according to a configurable security policy 1340 prevents certain telemetry data (such as telemetry data associated with a trusted execution environment) from being aggregated by the OOB-MSM. OOB-MSM 1321 reports aggregated telemetry data outward to an external agent (such as orchestrator 1350 or baseboard management controller (BMC)) using in-band and / or out-of-band channels (eg, according to a telemetry API).

[0120] In one embodiment, the PM agents 1311-1312 of the cores 1301-1302 periodically send telemetry data to the non-core unit 1322 and / or OOB-MSM 1321 through an out-of-band channel, respectively, which aggregates telemetry data from all sources and reports the telemetry data to the remote agent 1350 periodically and / or on demand. Alternatively or additionally, the telemetry data can be sent asynchronously based on defined event triggers on the core (e.g., scheduling a new workload on the IP core). In a trusted environment, only the cores 1301-1302 are aware of the trusted environment execution state and can enter and exit the TEE based on the instruction sequence being processed. In a specific implementation, the core flow that causes it to enter TEE mode includes but is not limited to: ACM boot – GETSEC[SENTER], GETSEC[ENTERACCS], ACM boot on reset (for Boot Guard) SGX enclave entry – ENCLU[EENTER], ENCLU[ERESUME] SEAM module entry – SEAMCALL, TD VM exit

[0121] The core flows that make it exit TEE mode include: ACM Disassembly – GETSEC[EXITAC] SGX enclave exit - ENCLU[EEXIT], Asynchronous enclave exit (AEX) The SEAM module exits –SEAMCALL, and the TD VM enters the PMT-profiled TD.

[0122] Building TEE execution awareness in the cores 1301-1302 requires tracking of any potential TEE nesting. Currently, the cores 1301-1302 support TEE nesting as shown in the following table. The concept of TEE nesting is critical to properly managing the "in-TEE" execution context. SoC Awareness for “In-TEE” Context

[0123] Management of execution contexts within a Trusted Execution Environment (i.e., “in-TEE” contexts) is typically localized to the core execution engine(s) associated with the TEE. Thus, proper handling of telemetry in the SoC requires building “in-TEE” awareness for the SoC telemetry aggregator, which may be integral to the OOB-MSM or other shared SoC components. For more advanced telemetry metrics (such as per-VM or per-workload metrics), cross-SoC awareness of the TEE context is required. Specific VMs and workloads may be running across several execution engines simultaneously while being evicted for I / O operations.

[0124] In one embodiment, each core 1301-1302 passes TEE context awareness information to a presentation layer circuit that filters telemetry data packets that are potentially contaminated with TEE context information. In this embodiment, the associated core 1301-1302 implements a tainted packet counter (TPC), which is an 8-bit (or more bit) counter that increments when the core executes in the TEE. Using periodic information packets sent through a potentially lossy fabric interconnect within the SoC, the counter value is passed to a telemetry aggregator (e.g., within the OOB-MSM). Bit flags may be used instead of or in addition to counters. However, in some embodiments, counters are used instead of bit flags to support filtering of frequent TEE entry-exit flows and to manage situations when specific updates to telemetry information packets or telemetry metrics are lost due to the structure or due to message buffering mechanisms. Embodiments of the present invention can be implemented on SoCs with different types of fabric interconnects and buffering mechanisms, including but not limited to those mechanisms for which there is no delivery guarantee and / or associated with specifically tailored attacks for exposing telemetry. For example, a lossy messaging protocol may be used, and potential message losses may be compensated at the metric level. These embodiments may be used for tracking as well as telemetry, and in any other situation where instruction / data processing metrics are needed.

[0125] Fig.14 The diagram includes an embodiment of filtering logic 1425 and telemetry aggregator 1321, one or both of which can be integrated within the OOB-MSM or other SoC level components. In one embodiment, packet filtering is performed by filtering logic 1425, and aggregation of unfiltered telemetry data is performed by telemetry aggregator 1321.

[0126] In the illustrated example, the core 1301 is shown executing different microcode (uCode) sequences 1410, including an IN_TEE bit 1411, which is used to indicate when the core is executing in TEE mode (e.g., 1401, 1403), and a STICKY_INTEE bit 1412, which is used to indicate when the core is executing in TEE mode and remains set for a period of time after the TEE execution has ended (i.e., not immediately reset when the TEE exits 1402, 1404). A polluted packet counter (TPC) 1413 counts when the core is in TEE mode and various telemetry data 1412 is transmitted to the telemetry aggregator 1321 in the form of periodic telemetry data packets 1421-1426. In this example, when core 1301 enters TEE mode at 1401 and 1403, TPC 1413 included in periodic telemetry information packets 1421-1422 begins to increment to indicate that telemetry packets 1422-1425 received by telemetry aggregator 1321 are tainted because they contain telemetry data collected when the core was executing in TEE mode in the past.

[0127] In one embodiment, the filtering logic 1425 determines, based on the defined security policy 1440, whether each specific telemetry data packet 1421-1426 should be filtered (rather than aggregated), whether a defined SNR (telemetry conditioning) should be added, and / or whether the telemetry packet should be passed over for inclusion in the aggregated telemetry data. Fig.14 1321, but the filtering logic 1425 may be implemented as an integrated circuit within the telemetry aggregator 1321 (eg, within an OOB-MSM circuit).

[0128] In one embodiment, based on the security policy 1440, any telemetry data from the contaminated data packets 1422-1425 is not aggregated and is filtered by the filtering logic 1425. The following unified modeling language (UML) code sequence represents one implementation, which also shows the case of lost data packet handling. The filtering mechanism for contaminated telemetry data packets can also be enhanced to add a user-defined noise level instead of removing all contaminated samples from the aggregated telemetry metrics. @startuml skinparam sequenceMessageAlign center participant"Core PUSH\n Telemetry"as core box"Ocode"#LightGreen participant"Data processing layer\n(Telemetry aggregation)"as ocode participant“Presentation layer\n(PMT API)”as pmt end box autonumber rnote over core,ocode Initial conditions:TPC=0,in_TEE=1'b0.No telemetry or info packetarrived yet. All previous counter values are 0,all deltas are 0,all per counterTPC are0. (TPC==Tainted Packet Counter,or in_TEE counter) end rnote ocode->pmt:No Info packet assume TPC=0 core -> ocode : Telemetry counter A=10 packet (first) ocode->pmt:Store A.Previous=10;calculate A.Delta=10;store A.TPC=0 core->ocode:Telemetry counter B=12 packet ocode->pmt:Store B.Previous=12;calculate B.Delta=12;store B.TPC=0 core->ocode:Telemetry counter C=23 packet ocode->pmt:Store C.Previous=23;calculate C.Delta=23;store B.TPC=0 rnote over ocode Until first info packet arrives,MSM Aggregator only calculates theinternal counter values.PMT stores per-counter TPC value. end rnote core->pmt:Info packet.TPC=0 activate pmt pmt->pmt:Expose counters A,B and C\n set A.TPC=0,B.TPC=0,C.TPC=0,PrevTPC=0 core->ocode:Telemetry counter A=15 packet deactivate pmt ocode->pmt:Store A.Previous=15;calculate A.Delta=5 core->core:Core enters TEE mode\nin_TEE=1 activate core core->ocode:Telemetry counter B=20 packet ocode->pmt:Store B.Previous=20;calculate B.Delta=8 core->ocode:Telemetry counter C=32 packet ocode->pmt:Store C.Previous=32;calculate C.Delta=9 core->pmt:Info packet.TPC=1 activate pmt rnote over pmt Packet is tainted.No telemetry shall be exposed. end rnote pmt->pmt:A.TPC!=TPC\n A.Delta=0 and A.TPC=1pmt->pmt:B.TPC!=TPC\n B.Delta=0 and B.TPC=1pmt->pmt:C.TPC!=TPC\n C.Delta=0 andC.TPC=1core->ocode:Telemetry counter A=21 packet deactivate pmtocode->pmt:Store A.Previous=21;calculate A.Delta=6core-x ocode:Telemetry counter B=24packet rnote over ocode:Packet lost.B.Previous=20 core->core:Core exits TEE mode\nin_TEE=0 deactivate core core->ocode:Telemetry counter C=36 packet ocode->pmt:StoreC.Previous=36;calculate C.Delta=4core->pmt:Info packet.TPC=2 activate pmt rnote over pmt Packet is tainted.No telemetry shall be exposed.B.TPC is not updated,since counter B was lost.(B.TPC=1) end rnotepmt->pmt:A.TPC! =TPC\n A.Delta=0 and A.TPC=2pmt->pmt:C.TPC! =TPC\n C.Delta=0 and C.TPC=2core->ocode:Telemetry counter A=30packet deactivate pmtocode->pmt:Store A.Previous=30;calculate A.Delta=9core->ocode:Telemetry counter B=42 packet ocode->pmt:Store B.Previous=42;calculate B.Delta=22core->ocode:Telemetry counter C=40packet ocode->pmt:Store C.Previous=40; calculate C.Delta=4core->pmt:Info packet.TPC=2 activate pmt rnote over pmt Packet is not tainted,but counter B was lost and now the delta contains the tainted cycles.Ocode cannot expose counter(B.TPC=1)(Ocode detected B.TPC counter increase) end rnote pmt->pmt:Expose aggregated\ncounters A and C pmt->pmt:B.TPC! =TPC\nB.Delta=0and B.TPC=2 deactivate pmt @enduml (@startuml skinparam sequence message alignment center Participant "Core Push\nTelemetry" as core box "Ocode" #LightGreen Actor "Data Processing Layer\n(Telemetry Aggregation)" as ocode Participant "Presentation Layer\n(PMT API)" as pmt end box Automatic numbering rnote for core and ocode Initial conditions: TPC = 0, in_TEE = 1'b0. No telemetry or information packet has arrived yet. All previous counter values ​​are 0, all increments are 0, and all TPC per counter is 0. (TPC == polluted packet counter, or in_TEE counter) end rnote ocode->pmt: no information packet, assuming TPC = 0 core->ocode: Telemetry counter A = 10 group (first) ocode->pmt: store A.Previous = 10; calculate A.Delta = 10; store A.TPC = 0 core->ocode: telemetry counter B = 12 packets ocode->pmt: store B.Previous = 12; calculate B.Delta = 10; store B.TPC = 0 core->ocode: telemetry counter C = 23 packets ocode->pmt: store C.Previous=23; calculate C.Delta=10; store C.TPC=0 rnote for ocode Until the first information packet arrives, the MSM aggregator only calculates internal counter values. The PMT stores the TPC values ​​per counter. end rnote core->pmt: information packet.TPC=0 Activate pmt pmt->pmt: Expose counters A, B, and C\nSet A.TPC=0, B.TPC=0, C.TPC=0, PrevTPC=0 core->ocode: Telemetry counter A = 15 groups Deactivate pmt ocode->pmt: store A.Previous = 15; calculate A.Delta = 5 core->core: core enters TEE mode\nin_TEE=1 Activate the core core->ocode: telemetry counter B = 20 group ocode->pmt: store B.Previous = 20; calculate B.Delta = 8core->ocode: telemetry counter C = 32 group ocode->pmt: store C.Previous = 32; calculate C.Delta = 9core->pmt: information group.TPC = 1 Activate pmt Rnote for PMT The packet is tainted. No telemetry will be exposed. end rnote pmt->pmt:A.TPC!=TPC\n A.Delta=0 and A.TPC=1pmt->pmt:B.TPC!=TPC\n B.Delta=0 and B.TPC=1pmt->pmt:C.TPC!=TPC\n C.Delta=0 and C.TPC=1core->ocode: telemetry counter A=21 packets deactivate pmt ocode->pmt: store A.Previous=21; calculate A.Delta=6 core->x ocode: telemetry counter B=24 packet_rnote for ocode: packet_lost.B.Previous=20 core->core: core enters TEE mode\nin_TEE=0 disables the core core->ocode: telemetry counter C = 36 packets ocode->pmt: store C.Previous = 36; calculate C.Delta = 4 core->pmt: information packet.TPC = 2 Activate pmt Rnote for PMT The packet is tainted. No telemetry data will be exposed. B.TPC Not updated because counter B is lost. (B.TPC=1) end rnote pmt->pmt:A.TPC! =TPC\n A.Delta=0 and A.TPC=2 pmt->pmt: C.TPC!=TPC\n C.Delta=0 and C.TPC=2 core->ocode: Telemetry counter A = 30 packets Deactivate pmt ocode->pmt: store A.Previous = 30; calculate A.Delta = 9 core->ocode: telemetry counter B = 42 packets ocode->pmt: store B.Previous = 42; calculate B.Delta = 22 core->ocode: telemetry counter C = 40 packets ocode->pmt: store C.Previous = 40; calculate C.Delta = 4 core->pmt: information packet.TPC=2 Activate pmt Rnote for PMT The packet is not corrupted, but counter B is lost and is now incremented Contains a polluted loop. Ocode cannot expose the counter (B.TPC=1) (Ocode detected B.TPC counter increased) end rnote pmt->pmt: expose aggregated\ncounters A and C pmt->pmt: B.TPC!=TPC\nB.Delta=0 and B.TPC=2 Deactivate pmt @enduml)

[0129] One embodiment of the OOB-MSM filtering logic is implemented by the OOB-MSM presentation layer, as described in the code sequence below. In this embodiment, the OOB-MSM presentation layer performs filtering of telemetry data. / / When any telemetry data packet (including telemetry counters) is received: Telem.Delta+=abs(P.Counter-Telem.PrevVal) Telem.PrevVal = P.Counter Telem.PacketReceived = TRUE / / Will be cleared whenever P.TaintedCtr is received / / When receiving a periodic information packet (including TPC): CCP.TaintedCtr = P.TaintedCtr currentTime = GetTime() / / read the time only once to avoid TOCTOU if((currentTime-CCP.PrevInfoTime)>=(3*PERIOD)) / / More than 30 packets are lost. Async CCP.TaintedCtr++ / / If more than 30 consecutive packets are lost, the telemetry is corrupted CCP.PrevInfoTime=currentTime; / / Continue processing all telemetry for CCP and store the current taintedCtr: For each(Telem=GetTelemetry(CCP)) / / Iterate over all counters of the CCP core if(Telem.PacketReceived) / / Received a packet with telemetry between information packets if(CCP.TaintedCtr!=Telem.PrevTaintedCtr) / / Did enter TEE since last grouping Then Telem.Delta=0 / / The group is polluted. Increment is reset to zero Telem.Sum+=Telem.Delta Telem.PrevTaintedCtr=CCP.TaintedCtr / / Store the current 8-bit contaminated counter Telem.PacketReceived = FALSE; / / Packet is processed Telem.Delta = 0;

[0130] Figure 15A-Figure 15C An example set of transactions between core 1301, telemetry aggregator 1321, and presentation layer 1425 according to some embodiments of the invention is illustrated. In some implementations, telemetry aggregator 1321 and presentation logic 1425 include circuits within the OOB-MSM, although the underlying principles of the invention are not limited to any particular arrangement of these components.

[0131] The initial conditions are as follows: the polluted packet counter (TPC) is 0, as indicated at 1501; the bit in the TEE is 1; a telemetry or information packet has not yet arrived; all previous counter values, all increments, and all per-counter TPCs are 0. Until the first telemetry packet arrives, the telemetry aggregator 1321 receives only internal counter values. In the illustrated example, this includes counter values ​​for telemetry counter A at 1502, telemetry counter B at 1504, and telemetry counter C at 1506. In each case, the telemetry aggregator 1321 transmits an indication of the counter value and counter value increment (i.e., change in the counter) to the presentation logic 1425 represented in transactions 1503, 1505, and 1507, which stores each corresponding counter value.

[0132] Thus, until the first information packet arrives, the telemetry aggregator 1321 only calculates internal counter values, and the rendering logic stores the counter-by-counter TPC values ​​A.TPC, B.TPC, and C.TPC (all initially set to zero).

[0133] In response to the first telemetry information packet (which indicates an unchanged TPC value of 0) at 1508, the presentation logic 1425 exposes the counter values ​​for counters A, B, and C and sets the corresponding TPC values ​​to 0 (i.e., sets A.TPC=0, B.TPC=0, C.TPC=0).

[0134] At 1510 , the core transmits the updated counter value for Counter A to the telemetry aggregator. At 1511 , the telemetry aggregator communicates the new value of Counter A and the increment for Counter A to the presentation logic 1425 .

[0135] At 1512, the core 1301 enters TEE mode (thereby setting the TEE bit to 1 to indicate TEE mode), and at 1513 and 1515, the updated counter values ​​for counter B and counter C are transmitted to the telemetry aggregator 1321, respectively, and at 1514 and 1516, the telemetry aggregator 1321 transmits corresponding messages containing the updated counter values ​​to the presentation logic 1425, respectively.

[0136] At 1517, the core pushes a telemetry information packet to the presentation logic 1425 with an updated TPC value of 1. The incremented TPC value indicates to the presentation logic 1425 that the core 1301 has entered TEE mode (i.e., because the TPC is only incremented when in TEE mode). The presentation logic 1425 records the TPC value of 1 at 1518-1520 and resets the increment value for each of the three counters to 0.

[0137] At 1521 and 1523, the core pushes updated counter values ​​for counter A and counter B, respectively, to the telemetry aggregator 1321. At 1522, the telemetry aggregator 1321 transmits the updated counter value and increment value for counter A to the presentation logic 1425. However, the packet containing the value for counter B in transaction 1523 is lost. The core then exits TEE mode at 1524, changing the TEE bit to a value of 0 to indicate that the TEE mode is no longer active.

[0138] At 1525 , the core 1301 transmits the new value for counter C to the telemetry aggregator 1321 , and at 1526 , the telemetry aggregator 1321 passes the counter value and corresponding increment for counter C to the presentation logic 1425 .

[0139] At 1527, the core pushes a telemetry information packet to the presentation logic 1425 with an updated TPC value of 2. Due to the incremented TPC value, the presentation logic does not expose telemetry data, thereby setting the increment values ​​for Counter A and Counter C to 0. Due to the lost packet with Counter B value at 1523, the TPC associated with Counter B (B.TPC) is not updated.

[0140] At 1530 , 1532 , and 1534 , core 1301 transmits new counter values ​​for counter A, counter B, and counter C, respectively, to telemetry aggregator 1321 , which transmits corresponding messages 1531 , 1533 , and 1535 containing the new counter values ​​and increment values ​​to presentation logic 1425 .

[0141] At 1536, core 1301 transmits a new information packet with the same TPC value as the TPC value transmitted at 1527, indicating that core 1301 is no longer in TEE mode (which would be identified with an incremented TPC counter value). Thus, at 1537, presentation logic 1537 exposes the aggregated counter values ​​for counter A and counter C due to the lost packet with counter B data at 1523, and resets the increment value for counter B to 0, and sets the TPC associated with counter B to 2. Preventing message storms

[0142] In one embodiment, the TPC is an 8-bit counter that wraps around every 256 telemetry update cycles. Thus, fewer packets lost during the TEE will not cause telemetry leakage. In some implementations, a timestamp is used to detect any more significant sample loss - i.e., measuring the time when the previous message was received. Using a relatively small 8-bit counter and adding a timestamp protects the telemetry data from any potential message storms or side channel attacks. When widespread message loss is detected using timestamps, one embodiment of the telemetry aggregator assumes that the samples were collected during execution "in the TEE" on a specific execution engine. Control of telemetry exposure from TEE by workload owners

[0143] Certain embodiments allow for per-workload control of telemetry exposure by the TEE. For example, with these embodiments, a TEE workload owner has the option to allow or deny the collection of telemetry data for the TEE. If such telemetry is allowed, aggregation from the TEE telemetry is performed even if trusted execution context data is recorded. In some embodiments, configuration options are included in a trust domain (TD) manifest that can be updated by a workload owner to enforce specific settings for telemetry collection.

[0144] Trust domain attestation operations may be relied upon by these embodiments. In one embodiment, an externally visible trust domain attribute "PMT profiled" is defined to provide telemetry data collection for cloud service providers (CSPs). In one embodiment, the trust domain attestation operations are as follows: The host VMM determines whether to set this property on a per-trust domain basis. This determination can be based on the trust domain inventory, cloud service provider policies, and potentially other variables. The Trust Domain Report Validator determines whether the profiled trust domain is trustworthy. For example, this determination may be made based on trust domain requirements, knowledge of the cloud service provider, and potentially other variables.

[0145] Embodiments of the present invention allow multiple policies to be defined so that workload owners can decide on a specific subset of telemetry exposure for each trust domain. Controlling telemetry exposure from TEE

[0146] The periodic information packets 1421-1426 sent by the core 1301 can also be used to convey telemetry policy. The telemetry policy, combined with the "in TEE" awareness, can then be used by the presentation logic 1425 to implement configurable control over the telemetry exposure policy (e.g., based on configuration options specified by the CSP). When the core 1301 collects telemetry data during execution "in the TEE", the presentation logic 1425 applies the telemetry policy. Based on the telemetry policy, only certain telemetry classes are exposed by the presentation layer 1425 during execution "in the TEE". In some implementations, the telemetry policy is dynamically generated at runtime based on a license (e.g., an OEM license), which is a contract between the OEM / CSP and the customer (e.g., a workload owner) that allows a certain subset of telemetry to be exposed in the TEE.

[0147] The following provides an example of permission in a Unified Modeling Language (UML) class code: @startuml class TelemetryXML_DMR{ -GUID -- #Container1 #Container2 #Container3 #Container4 #Container5 -- -Signature } Interface TelemetryPermit_CSP{ -class{"Class All,"Tier1","Tier2" -GUID -- #Container1_enabled bit #Container2_enabled bit #Container3_enabled bit #Container4_enabled bit #Container5_enabled bit -- -Hash "hash of TelemetryXML_DMR" -OEMSingature } Note right Permit provisioned into SoC in runtime Signed by CSP. Future:SNR(function and noise level) endnote Protocol SPDM_Hash{ #HashSoCFW #HashACM #TelemetryPermitAll #TelemetryPermitTier1 #TelemetryPermitTier2 -SPDM_GetMeasurements() } Note right Permit Hash in runtime reported via SPDM GetMeasurements()Each permit is reported as a separate Hash endnote TelemetryXML_DMR "1" *-- "many" TelemetryPermit_CSP:drives<TelemetryPermit_CSP“many”o--“1”SPDM_Hash:aggregate> @enduml (@startuml class TelemetryXML_DMR{ -GUID -- #Container 1 #Container 2 #Container 3 #Container 4 #Container 5 -- -sign } Interface Telemetry License_CSP{ -Class {"all classes","tier 1","tier 2" -GUID -- #CONTAINER1_ENABLE_BITS #CONTAINER2_ENABLE_BITS #Container3_enablebit #Container4_enable_bits #CONTAINER5_ENABLE_BIT -- -Hash "Hash of Telemetry XML_DMR" -OEM Signature } Note right Provision of licenses into the SoC at runtime Signed by the CSP Future: Signal-to-Noise Ratio (Functionality and Noise Level) endnote Protocol SPDM_Hash{ #HashSoCFW #HashACM #telemetry permission all #Telemetry permission level 1 #Telemetry permission level 2 - SPDM_GetMeasurement() } Note right License runtime hash reported via SPDM GetMeasurements() Each license is reported as a separate hash endnote telemetryxml_dmr "1" * -- "many" telemetrylicense_csp:driver< Telemetry License_CSP "many" o_ "1" SPDM_Hash: Aggregate> @enduml)

[0148] In one embodiment, a telemetry superset description is provided (e.g., in a collection of XML files or using another format). Based on this superset description, the OEM / CSP can generate a license that indicates a subset of telemetry data that will be available in the TEE. For example, this license can be protected by signing it using an X.509 certificate. The license is provided to the SoC, which uses the license to generate a telemetry policy that is then implemented by the presentation logic 1425. For example, the presentation logic uses the telemetry policy to detect TEE execution and make decisions about whether to expose certain telemetry. Multiple policies can be configured on a single SoC or a system containing SoCs, thereby enabling multi-layer telemetry level reporting.

[0149] In one implementation, a base policy is specified that enables filtering of certain telemetry associated with the TEE. More advanced policies may be specified that implement (among other things) telemetry throttling based on specified permissions. Telemetry throttling refers to modifying telemetry data (e.g., by adding predefined random noise) to reduce telemetry accuracy and make it less vulnerable to side-channel attacks. In one embodiment, a telemetry policy may define specific signal-to-noise ratio (SNR) thresholds for certain telemetry data. For example, when the core is in TEE mode, certain telemetry may be disabled or filtered, or made less accurate (e.g., if the associated SNR is below a threshold).

[0150] As mentioned, the license can be protected with a signature and / or certificate (e.g., an X.509 certificate). In one particular implementation, the license can be verified by the workload owner (or other entity) using the attestation capabilities defined in the Security Protocol and Data Model (SPDM) architecture. For example, in some embodiments, the SoC reports the license hash as a SoC measurement that can be obtained during the SPDM SoC attestation flow.

[0151] Thus, embodiments of the present invention provide entities such as CSPs and workload owners with mechanisms for controlling telemetry exposure, thereby enabling complete transparency and knowledge related to telemetry exposure. These embodiments also implement a multi-tier trusted computing platform, where each tier supports different levels of telemetry exposure depending on the plans (tiers) purchased by the workload owner from the CSP, which can range from fully blocked telemetry to a fully managed platform. Workload owners will also be provided with the ability to attest to the level of telemetry exposure.

[0152] exist Fig.16 A method according to one embodiment of the present invention is illustrated in FIG. The method can be implemented on various architectures described herein, but is not limited to any specific processor or system architecture.

[0153] At 1601, a telemetry security policy is generated based on permissions. As mentioned, permissions can be specified in UML code or other data formats. At 1602, instructions are executed in different execution contexts, including a trusted execution context, and corresponding telemetry data is collected and periodically transmitted.

[0154] If it is determined at 1603 that the telemetry data is received from a trusted execution context, then at 1604, the telemetry data is filtered according to the telemetry security policy. In either case, at 1605, the telemetry data is aggregated, excluding any portion that is filtered based on the security policy. For example, in some of the above embodiments, the filtering is performed by circuitry within a shared area of ​​the SoC. At 1606, the aggregated telemetry data is transmitted to an external agent, such as an orchestrator or BMC.

[0155] Example

[0156] The following are example implementations of different embodiments of the invention.

[0157] Example 1. A processor comprising: a plurality of processing cores for executing instructions in different execution contexts, the different execution contexts including a trusted execution context associated with a trusted execution environment; a telemetry aggregation circuit for aggregating telemetry data associated with one or more of the different execution contexts; a filtering circuit for preventing at least a portion of the telemetry data associated with the trusted execution context from being aggregated by the telemetry aggregation circuit; and an interface for transmitting the telemetry data aggregated by the telemetry aggregation circuit to an external agent.

[0158] Example 2. The processor of Example 1, wherein the filtering circuit comprises circuitry configurable based on a specified telemetry security policy.

[0159] Example 3. The processor of example 1 or 2, wherein the telemetry security policy includes an instruction that the filtering circuitry is to filter all or a specified subset of telemetry data associated with the trusted execution context.

[0160] Example 4. The processor of any of Examples 1 to 3, wherein the telemetry security policy is provided in a cryptographically protected license.

[0161] Example 5. The processor of any of Examples 1 to 4, wherein the cryptographically protected license includes a data structure formatted according to a particular modeling language or markup language to specify parameters for the telemetry security policy, and the data structure is cryptographically protected with a signature.

[0162] Example 6. The processor of any of Examples 1 to 5, wherein the telemetry security policy is dynamically generated at runtime of one of the execution contexts based on the permissions.

[0163] Example 7. The processor of any of Examples 1 to 6, further comprising: a plurality of counters, each counter being associated with a processing core or a plurality of processing cores and configured to be incremented or decremented when a corresponding processing core executes instructions in a trusted execution context.

[0164] Example 8. The processor of any one of Examples 1 to 7, further comprising: a plurality of agents corresponding to the plurality of processing cores, each agent to transmit a portion of the telemetry data associated with the corresponding processing core.

[0165] Example 9. The processor of any one of Examples 1 to 8, wherein the interface comprises an out-of-band interface accessible to an external agent via an application programming interface (API).

[0166] Example 10. A method comprising: executing instructions on a plurality of processing cores in different execution contexts, the execution contexts including a trusted execution context associated with a trusted execution environment; transmitting telemetry data from one or more processing cores of the plurality of processing cores in the different execution contexts; filtering at least a portion of the telemetry data associated with the trusted execution context to prevent aggregation by telemetry aggregation circuitry, the telemetry aggregation circuitry being operable to aggregate telemetry data associated with one or more of the different execution contexts excluding the filtered portion of the telemetry data; and transmitting the telemetry data aggregated by the telemetry aggregation circuitry to an external agent.

[0167] Example 11. The method of Example 10, wherein filtering is performed by circuitry configurable based on a specified telemetry security policy.

[0168] Example 12. The method of example 10 or 11, wherein the telemetry security policy includes an instruction that the filtering circuitry is to filter all or a specified subset of the telemetry data associated with the trusted execution context.

[0169] Example 13. The method of any of Examples 10 to 12, wherein the telemetry security policy is provided in a cryptographically protected license.

[0170] Example 14. The method of any of Examples 10 to 13, wherein the cryptographically protected license comprises a data structure formatted according to a particular modeling language or markup language to specify parameters for the telemetry security policy, and the data structure is cryptographically protected with a signature.

[0171] Example 15. The method of Example 14, wherein the telemetry security policy is dynamically generated based on permissions at runtime of one of the execution contexts.

[0172] Example 16. The method of any of Examples 10 to 15, further comprising: incrementing or decrementing a counter in a core of the plurality of cores when the instruction is executed in the trusted execution context.

[0173] Example 17. The method of any of Examples 10 to 16, wherein transmitting the telemetry data is performed by an agent associated with the plurality of cores.

[0174] Example 18. The method of any of Examples 10 to 17, wherein the telemetry data is transmitted to the external agent from an out-of-band interface accessible by the external agent via an application programming interface (API).

[0175] Example 19. At least one machine-readable medium having program code stored thereon that, when executed by one or more processors, causes the one or more processors to perform operations, the operations comprising: executing instructions on a plurality of processing cores in different execution contexts, the execution contexts comprising a trusted execution context associated with a trusted execution environment; transmitting telemetry data from one or more of the plurality of processing cores in the different execution contexts; filtering at least a portion of the telemetry data associated with the trusted execution context to prevent aggregation by telemetry aggregation circuitry, the telemetry aggregation circuitry being operable to aggregate telemetry data associated with one or more of the different execution contexts excluding the filtered portion of the telemetry data; and transmitting the telemetry data aggregated by the telemetry aggregation circuitry to an external agent.

[0176] Example 20. The machine-readable medium of Example 19, wherein the filtering is performed by circuitry configurable based on a specified telemetry security policy.

[0177] Example 21. The machine-readable medium of example 19 or 20, wherein the telemetry security policy includes an instruction that the filtering circuit is to filter all or a specified subset of the telemetry data associated with the trusted execution context.

[0178] Example 22. The machine-readable medium of any of Examples 19 to 21, wherein the telemetry security policy is provided in a cryptographically protected license.

[0179] Example 23. The machine-readable medium of any of Examples 19 to 22, wherein the cryptographically protected license comprises a data structure formatted according to a particular modeling language or markup language to specify parameters for the telemetry security policy, and the data structure is cryptographically protected with a signature.

[0180] Example 24. The machine-readable medium of any of Examples 19 to 23, wherein the telemetry security policy is dynamically generated at runtime of one of the execution contexts based on the permissions.

[0181] Example 25. The machine-readable medium of any one of Examples 19 to 24, further comprising program code for causing the following operations:

[0182] When an instruction is executed in the trusted execution context, a counter in a core of the plurality of cores is incremented or decremented.

[0183] Example 26. The machine-readable medium of any of Examples 19 to 25, wherein transmitting the telemetry data is performed by an agent associated with the plurality of cores.

[0184] Example 27. The machine-readable medium of any of Examples 19 to 26, wherein the telemetry data is transmitted to the external agent from an out-of-band interface accessible by the external agent via an application programming interface (API).

[0185] Embodiments of the present invention may include the steps described above. These steps may be embodied as machine executable instructions, which may be used to cause a general or special processor to perform these steps. Alternatively, these steps may be performed by specific hardware components containing hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

[0186] As described herein, instructions may refer to a specific configuration of hardware such as an application-specific integrated circuit (ASIC) that is configured to perform certain operations or have predetermined functions or software instructions stored in a memory embodied in a non-transitory computer-readable medium. Thus, the techniques shown in the accompanying drawings can be implemented using code and data stored on and executed on one or more electronic devices (e.g., terminal stations, network elements, etc.). Such electronic devices use computer machine-readable media (internally and / or with other electronic devices through a network) to store and transmit code and data, such as non-transitory computer machine-readable storage media (e.g., disks; optical disks; random access memory; read-only memory; flash memory devices; phase change memory) and transient computer machine-readable communication media (e.g., electrical, optical, acoustic or other forms of propagation signals - such as carrier waves, infrared signals, digital signals, etc.). In addition, such electronic devices typically include a collection of one or more processors coupled to one or more other components (such as, one or more storage devices (non-transitory machine-readable storage media), user input / output devices (e.g., keyboards, touch screens and / or displays), and network connections). The coupling of the set of processors with other components is typically through one or more buses and bridges (also referred to as bus controllers). The storage device and signal carrying network traffic represent one or more machine-readable storage media and machine-readable communication media, respectively. Thus, the storage device of a given electronic device typically stores code and / or data for execution on the set of one or more processors of the electronic device. Of course, different combinations of software, firmware, and / or hardware can be used to implement one or more parts of an embodiment of the present invention. Throughout this specific embodiment, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention can be implemented without some of these specific details. In some instances, known structures and functions are not described in detail to avoid obscuring the subject matter of the present invention. Therefore, the scope and spirit of the present invention should be determined according to the appended claims.

Claims

1. A processor, comprising: a plurality of processing cores to execute instructions in different execution contexts, the different execution contexts including a trusted execution context associated with a trusted execution environment; telemetry aggregation circuitry for aggregating telemetry data associated with one or more of the different execution contexts; filtering circuitry to prevent at least a portion of telemetry data associated with the trusted execution context from being aggregated by the telemetry aggregation circuitry; as well as An interface for transmitting telemetry data aggregated by the telemetry aggregation circuit to an external agent.

2. The processor of claim 1, wherein: The filtering circuitry includes circuitry that is configurable based on a specified telemetry security policy.

3. The processor of claim 2, wherein: The telemetry security policy includes an instruction for the filtering circuit to filter all or a specified subset of telemetry data associated with the trusted execution context.

4. A processor as claimed in claim 2 or 3, wherein: The telemetry security policy is provided in an encryption-protected license.

5. The processor of claim 4, wherein: The cryptographically protected permission includes a data structure, the data structure is formatted according to a specific modeling language or markup language to specify parameters for the telemetry security policy, and the data structure is cryptographically protected with a signature.

6. The processor of claim 5, wherein: The telemetry security policy is dynamically generated based on the permission at runtime of one of the execution contexts.

7. The processor of any one of claims 1 to 6, further comprising: A plurality of counters, each counter being associated with a processing core or the plurality of processing cores and configured to be incremented or decremented when the corresponding processing core executes instructions in the trusted execution context.

8. The processor of any one of claims 1 to 7, further comprising: A plurality of agents corresponding to the plurality of processing cores, each agent being configured to transmit a portion of telemetry data associated with a corresponding processing core.

9. A processor as claimed in any one of claims 1 to 8, wherein: The interface comprises an out-of-band interface accessible to the external agent via an application programming interface (API).

10. A method comprising: executing instructions on the plurality of processing cores in different execution contexts, the execution contexts including a trusted execution context associated with a trusted execution environment; transmitting telemetry data from one or more of the plurality of processing cores in the different execution contexts; filtering at least a portion of telemetry data associated with the trusted execution context to prevent aggregation by telemetry aggregation circuitry, the telemetry aggregation circuitry being operable to aggregate telemetry data associated with one or more of the different execution contexts excluding the filtered portion of telemetry data; as well as The telemetry data aggregated by the telemetry aggregation circuit is transmitted to an external agent.

11. The method of claim 10, wherein: The filtering is performed by circuitry that is configurable based on a specified telemetry security policy.

12. The method of claim 11, wherein: The telemetry security policy includes an instruction for the filtering circuit to filter all or a specified subset of telemetry data associated with the trusted execution context.

13. The method according to claim 11 or 12, wherein: The telemetry security policy is provided in an encryption-protected license.

14. The method of claim 13, wherein: The cryptographically protected permission includes a data structure, the data structure is formatted according to a specific modeling language or markup language to specify parameters for the telemetry security policy, and the data structure is cryptographically protected with a signature.

15. The method of claim 14, wherein: The telemetry security policy is dynamically generated based on the permission at runtime of one of the execution contexts.

16. The method of any one of claims 10 to 15, further comprising: When instructions are executed in the trusted execution context, a counter in a core of the plurality of cores is incremented or decremented.

17. The method according to any one of claims 10 to 16, wherein: Transmitting telemetry data is performed by an agent associated with the plurality of cores.

18. The method according to any one of claims 10 to 17, wherein: The telemetry data is transmitted to the external agent from an out-of-band interface that is accessible by the external agent via an application programming interface (API).

19. At least one machine-readable medium having program code stored thereon, the program code, when executed by one or more processors, causing the one or more processors to perform operations comprising: executing instructions on the plurality of processing cores in different execution contexts, the execution contexts including a trusted execution context associated with a trusted execution environment; transmitting telemetry data from one or more of the plurality of processing cores in the different execution contexts; filtering at least a portion of telemetry data associated with the trusted execution context to prevent aggregation by telemetry aggregation circuitry, the telemetry aggregation circuitry being operable to aggregate telemetry data associated with one or more of the different execution contexts excluding the filtered portion of telemetry data; as well as The telemetry data aggregated by the telemetry aggregation circuit is transmitted to an external agent.

20. The machine-readable medium of claim 19, wherein: The filtering is performed by circuitry that is configurable based on a specified telemetry security policy.

21. The machine-readable medium of claim 20, wherein: The telemetry security policy includes an instruction for the filtering circuit to filter all or a specified subset of telemetry data associated with the trusted execution context.

22. The machine-readable medium of claim 20 or 21, wherein: The telemetry security policy is provided in an encryption-protected license.

23. The machine-readable medium of claim 22, wherein: The cryptographically protected permission includes a data structure, the data structure is formatted according to a specific modeling language or markup language to specify parameters for the telemetry security policy, and the data structure is cryptographically protected with a signature.

24. The machine-readable medium of claim 23, wherein: The telemetry security policy is dynamically generated based on the permission at runtime of one of the execution contexts.

25. The machine-readable medium of any one of claims 19 to 24, further comprising program code for causing the following operations: When instructions are executed in the trusted execution context, a counter in a core of the plurality of cores is incremented or decremented.

Images