Patent Description:
Existing performance monitoring units (PMUs) of processors are not designed to support security related profiling use cases. Existing PMUs are composed of a single user intellectual property (IP) block without a hardware-based arbitration mechanism. There is also no hardware-based mechanism to manage access to telemetry data for a specified process/container/virtual machine (VM) running on the processor. As a result, security related use cases, such as monitoring for malicious activities by untrusted processes, relies heavily on existing PMU sampling techniques that expose the sampling data and monitoring stack to user space interference and/or attacks. Patent document <CIT> is regarded as the closest prior art.

So that the manner in which the above recited features of the present embodiments can be understood in detail, a more particular description of the embodiments, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments and are therefore not to be considered limiting of its scope. The figures are not to scale. In general, the same reference numbers will be used throughout the drawings and accompanying written description to refer to the same or like parts.

Implementations of the technology described herein provide a method and system to securely configure a specific set of PMU counters for use by a software (SW) process that cannot be altered by other SW processes and to verify that associated data read from PMU counters has not been tampered with in the data path from the counter to the SW process. Embodiments provide a secure PMU (SPMU) within a processor that enables creation of secure counter groups in the SPMU with tamper-proof configurations and hardware (HW) root of trust (RoT)-backed verifiable counter data for security uses.

Embodiments provide a secure PMU extension augmenting an existing performance monitoring unit (PMU) IP block in a processor for enabling secure grouping of a specified set of PMU counters and allow for SW processes sampling data from the counters to verify the counter data with a HW RoT-backed public key. The secure extension comprises a new operational mode of the PMU that may be implemented, in an embodiment, with microcode. The SPMU introduces a dedicated set of performance monitoring counters (e.g., sets of two, four, eight or more counters, depending on capabilities of the processor) that can be programmed for managed access by a plurality of SW processes. The SW process (e.g., security SW running on the processor) setting up a secure counter group in the SPMU is cryptographically bound with the secure counter group that the SW process creates. The data gathered from the counters of the secure counter group are signed by a HW RoT-based key and copied to a set of model specific registers (MSRs), along with a signature, to be verified by the SW process that was assigned the secure counter group. Verification of counter data is done by a signing key with an HW RoT-backed public certificate maintained by the SPMU.

<FIG> is a diagram of a processor <NUM> including a SPMU <NUM> according to some embodiments. Processor <NUM> includes any number of hardwired or configurable circuits, some or all of which may include programmable and/or configurable combinations of electronic components, semiconductor devices, and/or logic elements that are disposed partially or wholly in a personal computer (PC), server, mobile phone, tablet computer, or other computing system capable of executing processor-readable instructions. SPMU <NUM> circuitry includes any number and/or combination of any currently available or future developed electronic devices and/or semiconductor components capable of monitoring one or more performance aspects and/or parameters of processor <NUM>. SPMU <NUM> may have any number and/or combination of performance monitoring counters <NUM>. Counters <NUM> are circuitry or logic elements used to count events that occur during processing by processor <NUM>. In embodiments, SPMU <NUM> includes circuitry to monitor, track, and/or count processor activity. For example, in an Intel® processor, SPMU <NUM> circuitry may be at least partially included or otherwise embodied in a performance monitoring unit (PMU).

In some implementations, SPMU <NUM> may include one or more configurable or programmable elements, such as one or more configurable integrated circuits, capable of executing machine-readable instruction sets that cause the configurable or programmable elements to combine in a particular manner to create the SPMU <NUM> circuitry. In some implementations, the SPMU <NUM> circuitry may include one or more stand-alone devices or systems, for example, the SPMU <NUM> circuitry may be embodied in a single surface- or socket-mount integrated circuit. In other implementations, the SPMU <NUM> circuitry may be provided in whole or in part via one or more processors, controllers, digital signal processors (DSPs), reduced instruction set computers (RISCs), systems-on-a-chip (SOCs), application specific integrated circuits (ASICs) capable of providing all or a portion of processors <NUM>.

The counters <NUM> may include any number and/or combination of currently available and/or future developed electrical components, semiconductor devices, and/or logic elements capable of monitoring, tracking, and/or counting events in processor <NUM>. Counters <NUM> include fixed counters <NUM> and general counters <NUM>. Fixed counters <NUM> include a plurality of counters that are permanently assigned to monitor, track, and/or count a specified event in processor <NUM>. General counters <NUM> include a plurality of counters that may be programmed by firmware to monitor, track, and/or count a defined event or condition in processor <NUM>.

In an embodiment, processor <NUM> includes a plurality of processing cores P1 <NUM>, P2 <NUM>,. PN <NUM>, where N is a natural number. Processing cores P1 <NUM>, P2 <NUM>,. PN <NUM> may read and/or write any of the fixed counters <NUM> and/or general counters <NUM>. SPMU <NUM> includes a plurality of model specific registers (MSRs) <NUM> to store information to be read and/or written by the plurality of processing cores P1 <NUM>, P2 <NUM>,.

Processor <NUM> executes instructions for a plurality of SW processes SW <NUM><NUM>, SW <NUM><NUM>,. SW M <NUM>, where M is a natural number. The SW processes may read and/or write MSRs <NUM>. In existing PMUs, SW processes SW <NUM><NUM>, SW <NUM><NUM>,. SW M <NUM> can access a PMU to program counters and read their data. Existing PMUs allow SW processes sampling counter data from the PMU full and unrestricted access to all counters and any SW process can override the sampling configuration set by another SW process. This can result in misconfiguration of counters <NUM> and, for example, SW <NUM><NUM> may read counter data configured by SW <NUM><NUM> without knowing that the counter data is configured by another SW process. This can also lead to malicious attacks, especially if the PMU counter data is being used for security purposes.

This lack of control over access to PMU counters is overcome by the technology described herein. In an embodiment, processor <NUM> includes a SPMU <NUM> including secure group manager <NUM> circuitry to securely manage access to fixed counters <NUM> and general counters <NUM>. Secure group manager creates secure counter groups, manages sampling of data from counters <NUM>, and deletes secure counter groups.

The secure group manager <NUM> circuitry may include any number and/or combination of currently available and/or future developed electrical components, semiconductor devices, and/or logic elements capable of managing secure counter groups. In an embodiment, the secure group manager <NUM> may be formed by the execution of machine-readable instruction sets associated with an application and/or service executed in ring <NUM> kernel space. In embodiments, SPMU <NUM> may provide some or all the secure group manager <NUM> circuitry. In other embodiments, the processor <NUM> may provide some or all the secure group manager <NUM> circuitry upon executing one or more machine readable instruction sets.

Although not depicted in <FIG>, in embodiments, a memory or similar storage device may be coupled to the SPMU <NUM> circuitry. The SPMU <NUM> may cause the storage of some or all the data from counters <NUM> in the memory or storage device. In at least some embodiments, some or all the data stored in the memory or storage device may be accessible to a user of processor <NUM>.

<FIG> is a diagram of a SPMU arrangement <NUM> according to some embodiments. Secure group manager <NUM> circuitry in SPMU <NUM> manages creation, deletion, and runtime operations of secure container groups, and verifies secure counter group configuration updates. Secure group manager <NUM> creates one or more secure groupings of a specified set of counters <NUM> (e.g., zero or more fixed counters and zero or more general counters) and allows SW processes sampling counter data to verify the counter data with a HW RoT-backed public key. Any SW process (such as SW I <NUM>, SW J <NUM>, and SW K <NUM>, which are examples of SW processes SW <NUM><NUM>, SW <NUM><NUM>,. SW M <NUM> of <FIG>) can configure a dedicated set of fixed counters <NUM> and/or general counters <NUM> (e.g., sets of two, four, or eight counters, more or less depending on capabilities of processor <NUM>) that can be programmed to track one or more events occurring during processing by processor <NUM>.

A set of assigned counters is referred to herein as a secure counter group. The SW process setting up a secure counter group (e.g., security SW) is cryptographically bound with the secure counter group and will be considered to 'own' that group. For example, SW I <NUM> may read one or more of a selected one or more of fixed counters <NUM> and general counter (GC) A <NUM> and GC B <NUM>. In this example, no secure counter group is created, and no security is provided by SPMU to manage access to these counters. For example, another SW process, SW J <NUM>, may request that secure group manager <NUM> create a secure group, such as group <NUM><NUM>, that includes GC D <NUM> and GC F <NUM>. Once this secure counter group is created, only SW J <NUM> may configure the counters in the group. This security arrangement is shown in <FIG> by the dashed box <NUM> for SW J <NUM>. For example, another SW process, SW K <NUM>, may request that secure group manager <NUM> create another secure group, such as group <NUM><NUM>, that includes GC H <NUM>,. GC P <NUM>. Once this secure counter group is created, only SW K <NUM> may configure the counters in the group. This security arrangement is shown in <FIG> by the dashed box <NUM> for SW K <NUM>. Generally, only the SW process that requested the creation of the secure counter group by SPMU <NUM> can configure and verify counters in that group. Counters are assigned exclusively to a one secure counter group at a time (e.g., a counter cannot be assigned to two or more groups simultaneously). Once assigned to a first secure counter group, a counter cannot be assigned to a second secure counter group until the first secure counter group is deleted. This provides additional security over SW processes reading counters that is not present in existing PMUs and/or processors.

In an embodiment, SPMU <NUM> generates a performance monitoring interrupt (PMI) when one or more of the events represented by counters in a secure counter group either crosses a predetermined threshold or completes a sampling interval. When a PMI is generated, the SW process that requested creation of the secure counter group in response to the PMI reads the counters of the secure counter group. In an embodiment, all counters in the group are read since the signature is on a hash of all counters combined.

Data from a secure counter group data is signed by a HW RoT-based key and copied to one or more MSRs <NUM>, along with a signature of the hash of the combined counter data, to be read by the SW process that owns the secure counter group. A new set of MSRs, called signature MSRs <NUM> herein, is introduced to enable reading of the secure counter group signature. For example, for SW J <NUM>, a signature S1 = {GC D || GC F}Ppriv (where Ppriv is a private key for the secure counter group) may be stored in a signature MSR. For example, for SW K <NUM>, a signature S2 = {GC H ||. || GC P}Ppriv may be stored in another signature MSR. Although the box representing signature MSRs <NUM> is shown in <FIG> as being not within any secure counter group (e.g., group <NUM><NUM>, group <NUM><NUM>), each secure counter group is associated, upon creation, with one of the signature MSRs <NUM>. SPMU <NUM> includes a plurality of counter MSRs <NUM> to control counters <NUM>. Each counter is associated with one or more counter MSRs. In an embodiment, there are two counter MSRs for each counter - one for configuring the counter and one for reading counter data.

In an embodiment, SPMU <NUM> performs counter data verification using a RoT-backed public certificate maintained by the SPMU. SPMU secure group setup and key exchange are be done through an auxiliary security channel represented in <FIG> as security controller <NUM>. In various embodiments, security controller <NUM> may be implemented as converged security management engine (CSME), enhanced security engine (ESE), hardware security processor (HSP) (e.g., Pluton available from Microsoft® or Titan available from Google® for client devices) or baseboard management controller (BMC) (for servers). In other embodiments, a SW process may verify the counter data in existing secure endpoint containers such as Secure Guard Extensions (SGX), Trust Domain Extensions (TDX) or remotely in a server accessible over a network.

Embodiments described herein make use of cryptographic keys. Each SW process (e.g., SW <NUM><NUM>, SW <NUM><NUM>,. SW M <NUM> of <FIG>, or SW I <NUM>, SW J <NUM>, and SW K <NUM> of <FIG>) requesting a secure counter group has a cryptographic key pair Spub, Spriv with Spub being the public key and Spriv being the private key. Spub is shared with the SPMU during creation of a secure counter group. Subsequent updates to the secure counter group's counter configuration are required to be signed with the private key Spriv. This ensures only the secure counter group's creator/owner may update the group's configuration. Each SW process maintains Spriv and may store Spriv in a secure location (e.g., a trusted platform module (TPM), CSME, in the cloud, etc.).

Each created secure counter group is associated with a cryptographic key pair Ppub, Ppriv and an associated digital certificate PpubCert. The private key Ppriv is not disclosed outside of the SPMU. he public key Ppub of the secure counter group is shared by SPMU <NUM> with the sampling SW process that requested the group's creation. A public certificate PpubCert bound to a HW RoT for processor <NUM> is shared to validate Ppub. Counter data from a secure counter group is signed by SPMU with the private key Ppriv associated with the secure counter group. This enable the SW process to verify that the counter data has not been tampered within the data path from the SPMU to the SW process. In an embodiment, the secure counter group private key Ppriv is maintained in the SPMU internal secure storage and never exposed outside the SPMU in processor <NUM> or in a computing system having the processor. In an embodiment, processor <NUM> may generate derivative private keys and certificates for one or more boot sessions to provide additional security.

Keys and certificates associated with SPMU <NUM> configuration are exchanged through an auxiliary security channel denoted security controller <NUM> in <FIG> using existing well-known protocols. The data signing protocol and verification processes are not described herein as several options are available that can be used, such as hash-based message authentication code (HMAC)-secure hash algorithm (SHA)<NUM>/SHA384/<NUM>, etc. In an embodiment, a SPMU implementation may truncate the hash length to fit into limited MSR space available in processor <NUM>. In an embodiment, the functionality of security controller <NUM> as described herein may be included in SPMU <NUM>.

<FIG> is a flow diagram of secure group manager processing <NUM> according to some embodiments. At block <NUM>, secure group manager <NUM> of SPMU <NUM> receives a request to create a secure counter group with one or more counters from a SW process via security controller <NUM>. At block <NUM>, secure group manager <NUM> determines the availability of requested counters (e.g., those specified in the request), creates the secure counter group, assigns the one or more requested counters to the newly created secure counter group, and saves a public key of the requesting SW process (e.g., Spub). In an embodiment, secure group manager assigns a group identifier (ID) to the newly created secure counter group and saves the group ID along with the SW process's public key. These actions reserve the one or more assigned counters to the newly created secure counter group and they cannot be reserved by another SW process until the secure counter group is deleted and the counters are freed.

At block <NUM>, secure group manager <NUM> receives a private key for the secure counter group (e.g., Ppriv) from security controller <NUM>. Secure group manager <NUM> saves the private key for the secure counter group. Secure group manager <NUM> associates the saved private key is the group ID for the group. At block <NUM>, secure group manager <NUM> receives a request to configure a secure counter group from a SW process via security controller <NUM>. At block <NUM>, secure group manager <NUM> verify the configuration being requested using the previously saved public key of the requesting SW process (e.g., Spub). If the configuration is verified (e.g., the requested configuration came from the SW process that owns the secure counter group and the requested configuration is acceptable), sampling is begun. At block <NUM>, for a sample, secure group manager <NUM> updates one or more counter MSRs <NUM> and updates one or more signatures MSRs <NUM> with a hash of the data of the counters in the secure counter group signed with the private key of the secure counter group (e.g., Ppriv).

<FIG> is a flow diagram of create secure counter group processing <NUM> according to some embodiments. At block <NUM>, when a SW process <NUM> needs to set up a secure counter group in SPMU <NUM> to monitor, count, and/or track one or more counters <NUM> of processor <NUM>, SW process <NUM> starts a create group action. At block <NUM>, the SW process <NUM> generates the keys for use by the SW process and sends a create group request to SPMU <NUM> via security controller <NUM>. In an embodiment, the keys include a public key for the SW process (Spub) and an associated private key for the SW process (e.g., Spriv). In an embodiment, the SW process generates a new key pair for each secure counter group requested to be created. The create group request may include a number of fixed counters <NUM>, a number of general counters <NUM>, and the public key of the SW process. In an embodiment, the create group request includes counter IDs of the counters (whether fixed or general) requested to be included in the group.

At block <NUM>, security controller <NUM> receives the create group request, validates the request, and if validated, sends the create group request to secure group manager <NUM> in SPMU <NUM>. At block <NUM>, secure group manager <NUM> determines the availability of requested counters (e.g., those specified in the create group request), creates the secure counter group, assigns the one or more requested counters to the newly created secure counter group, and saves a public key of the requesting SW process (e.g., Spub). In an embodiment, secure group manager assigns a group identifier (ID) to the newly created secure counter group and saves the group ID along with the SW process's public key (e.g., Spub). These actions reserve the one or more assigned counters to the newly created secure counter group and they cannot be reserved by another SW process until the secure counter group is deleted and the counters are freed.

At block <NUM>, secure group manager <NUM> checks if the secure counter group was successfully created. If not, the group was not created, and processing continues at block <NUM>. In an embodiment, an error message may be returned to the requesting SW process <NUM> via security controller <NUM>. If so, secure group manager <NUM> sends a positive status indication back to security controller <NUM> along with the group ID of the newly created group. At block <NUM>, security controller generates keys for the newly created secure counter group along with a certificate. Thus, security controller <NUM> generates Ppriv, Ppub, and PpubCert. In an embodiment, the key pair is unique for every secure counter group being created. At block <NUM>, security controller <NUM> sends the private key for the newly created group along with the group ID to secure group manager <NUM>. At block <NUM>, secure group manager <NUM> saves the private key Ppriv for the group. The exchange of the Ppriv, Spub, and counter set, and subsequent storage in local SPMU data storage, completes initialization of the secure counter group. At block <NUM>, if initialization of the secure counter group failed, then the group was not created, and processing continues at block <NUM>. In an embodiment, an error message may be returned to the requesting SW process <NUM> via security controller <NUM>. If the initialization of the secure counter group was successful, secure group manager <NUM> notifies security controller <NUM>, and the security controller sends the group ID, the counter IDs of counters in the secure counter group, the public key for the secure counter group Ppub, and the group certificate PpubCert to the SW process <NUM>. At block <NUM>, SW process <NUM> receives and stores this information and validates the certificate against a trusted RoT. If the certificate is invalid at block <NUM>, create group processing has failed and processing ends at block <NUM>. Otherwise, the group was created processing is complete at block <NUM>.

<FIG> is a flow diagram of starting sampling processing <NUM> according to some embodiments. At block <NUM>, sampling is started by SW process <NUM>. At block <NUM>, the SW process configures group counters to generate a configuration and signs the configuration with the private key of the SW process (e.g., Spriv). This may be represented as [ct1config || ctr2config ||. ctrNconfig]Spriv (where N is the number of counters in the configuration).

In an embodiment, this is the stage when the SW process configures the SPMU group's general counters to start monitoring the desired HW events the PMU is capable of monitoring. The counter configuration comprises a set of tuples for each general counter in the group. Each tuple will represent [counter ID, counter event config] (e.g., [GC1, event #||umask||cmask] || [GC2, Event #||umask||cmask].

SW process <NUM> sends the configuration request to security controller <NUM>. At block <NUM>, security controller <NUM> validates the configuration request (e.g., for correct format and syntax), and if validated, sends the configuration request to secure group manager <NUM> of SPMU <NUM>. If the configuration request is invalid, security controller <NUM> returns an error status to the requesting SW process <NUM>. At block <NUM>, secure group manager <NUM> receives a request to configure a secure counter group from a SW process via security controller <NUM> and the secure group manager verifies the configuration being requested using the previously saved public key of the requesting SW process (e.g., Spub).

If the configuration is not verified at block <NUM>, setting the configuration and starting sampling is a failure at block <NUM>, and an error message may be returned to the SW process. If the configuration is verified (e.g., the requested configuration came from the SW process that owns the secure counter group and the requested configuration is acceptable), sampling is begun at block <NUM>. At block <NUM>, for a sample, secure group manager <NUM> updates one or more counter MSRs <NUM> and updates one or more signatures MSRs <NUM> with a hash of the data of the counters in the secure counter group signed with the private key of the secure counter group (e.g., Ppriv). At block <NUM>, for the current sample, SW process <NUM> reads the counter MSRs for counters associated with the secure counter group and the one or more signatures MSRs associated with the counters in the secure counter group. At block <NUM>, the SW process <NUM> verifies the hash from the signature MSRs with the public key of the secure counter group (e.g., Ppub). If the hash is verified at block <NUM>, then the sampling is a success at block <NUM> and the SW process can reliably and securely use the retrieved counter data. If the hash is not verified at block <NUM>, a failure has occurred and sampling processing ends at block <NUM>.

<FIG> is a flow diagram of delete secure counter group processing <NUM> according to some embodiments. When a secure counter group is no longer needed by the SW process that created the group, the group can be deleted to free the assigned counters for use by other SW processes. At block <NUM>, delete group processing is started by SW process <NUM>. At block <NUM>, SW process <NUM> signs a delete group request (including the group ID of the group to be deleted) with the private key of the SW process (Spriv) and sends the delete group request to the security controller <NUM>. This may be represented at [group ID || auxiliary data] Spriv. At block <NUM>, security controller <NUM> validates the request, and if validated, sends the delete group request to secure group manager <NUM> in SPMU <NUM>. If the delete group request is invalid, security controller <NUM> returns an error status to the requesting SW process <NUM>. At block <NUM>, secure group manager <NUM> receives the delete group request, and verifies the delete group request using the public key of the requesting SW process (e.g., Spub). At block <NUM>, if the signature is not verified, then a failure for the delete group request is indicated at block <NUM> and an error message may be returned to the SW process. An error may occur, for example, if the SW process requesting to delete the secure counter group identified by the group ID is not the SW process that created the secure counter group. However, sampling for the counters of the secure counter group continues.

At block <NUM>, if the signature is verified, then the SW process requesting the deleting of the group is the same SW process that created the group. At block <NUM>, secure group manager <NUM> stops sampling, frees the counters assigned to the secure counter group (so that they can be reassigned to another group in future), and deletes any storage associated with the now deleted secure counter group. For example, this may include the public key of the SW process that created/deleted the group (Spub), and the private key of the secure counter group (Ppriv). Delete group processing ends at success block <NUM>.

Embodiments provide a HW-based means of preventing tampering with PMU counters and enables HW RoT-backed verifiability of PMU configurations of secure counter groups and of counter data. This technology opens up a host of security use cases for the PMU counter data that is currently primarily used for workload optimization in debug environments. Threat profiling and monitoring SW (such as anti-virus (AV), endpoint platform protection (EPP), and endpoint detection and response (EDR) can use the capability described herein to securely and predictably monitor for malicious, as well as anomalous, activities with PMU telemetry data. Counter data can be collected in secure containers (e.g., such as like Intel® Software Guard Extensions (SGX) and Intel® Trust Domain Extensions (TDX) with tamper protection for processing. For example, this technology improves the security of solutions such as Intel® Threat Detection Technology (TDT) that depends on untampered and consistent PMU configurations and counter data.

<FIG> is a schematic diagram of an illustrative electronic computing device to perform security processing according to some embodiments. In some embodiments, computing device <NUM> includes one or more processors <NUM> including SPMU <NUM>. In some embodiments, the computing device <NUM> includes one or more hardware accelerators <NUM>.

In some embodiments, the computing device is to implement security processing, as provided in <FIG> above.

The computing device <NUM> may additionally include one or more of the following: cache <NUM>, a graphical processing unit (GPU) <NUM> (which may be the hardware accelerator in some implementations), a wireless input/output (I/O) interface <NUM>, a wired I/O interface <NUM>, system memory <NUM>, power management circuitry <NUM>, non-transitory storage device <NUM>, and a network interface <NUM> for connection to a network <NUM>. The following discussion provides a brief, general description of the components forming the illustrative computing device <NUM>. Example, non-limiting computing devices <NUM> may include a desktop computing device, blade server device, workstation, laptop computer, mobile phone, tablet computer, personal digital assistant, or similar device or system.

In embodiments, the processor cores <NUM> are capable of executing machine-readable instruction sets <NUM>, reading data and/or machine-readable instruction sets <NUM> from one or more storage devices <NUM> and writing data to the one or more storage devices <NUM>. Those skilled in the relevant art will appreciate that the illustrated embodiments as well as other embodiments may be practiced with other processor-based device configurations, including portable electronic or handheld electronic devices, for instance smartphones, portable computers, wearable computers, consumer electronics, personal computers ("PCs"), network PCs, minicomputers, server blades, mainframe computers, and the like. For example, machine-readable instruction sets <NUM> may include instructions to implement security processing, as provided in <FIG>.

The processor cores <NUM> may include any number of hardwired or configurable circuits, some or all of which may include programmable and/or configurable combinations of electronic components, semiconductor devices, and/or logic elements that are disposed partially or wholly in a PC, server, mobile phone, tablet computer, or other computing system capable of executing processor-readable instructions.

The computing device <NUM> includes a bus <NUM> or similar communications link that communicably couples and facilitates the exchange of information and/or data between various system components including the processor cores <NUM>, the cache <NUM>, the graphics processor circuitry <NUM>, one or more wireless I/O interface <NUM>, one or more wired I/O interfaces <NUM>, one or more storage devices <NUM>, and/or one or more network interfaces <NUM>. The computing device <NUM> may be referred to in the singular herein, but this is not intended to limit the embodiments to a single computing device <NUM>, since in certain embodiments, there may be more than one computing device <NUM> that incorporates, includes, or contains any number of communicably coupled, collocated, or remote networked circuits or devices.

The processor cores <NUM> may include any number, type, or combination of currently available or future developed devices capable of executing machine-readable instruction sets.

The processor cores <NUM> may include (or be coupled to) but are not limited to any current or future developed single- or multi-core processor or microprocessor, such as: on or more systems on a chip (SOCs); central processing units (CPUs); digital signal processors (DSPs); graphics processing units (GPUs); application-specific integrated circuits (ASICs), programmable logic units, field programmable gate arrays (FPGAs), and the like. Unless described otherwise, the construction and operation of the various blocks shown in <FIG> are of conventional design. Consequently, such blocks need not be described in further detail herein, as they will be understood by those skilled in the relevant art. The bus <NUM> that interconnects at least some of the components of the computing device <NUM> may employ any currently available or future developed serial or parallel bus structures or architectures.

The system memory <NUM> may include read-only memory ("ROM") <NUM> and random-access memory ("RAM") <NUM>. A portion of the ROM <NUM> may be used to store or otherwise retain a basic input/output system ("BIOS") <NUM>. The BIOS <NUM> provides basic functionality to the computing device <NUM>, for example by causing the processor cores <NUM> to load and/or execute one or more machine-readable instruction sets <NUM>. In embodiments, at least some of the one or more machine-readable instruction sets <NUM> cause at least a portion of the processor cores <NUM> to provide, create, produce, transition, and/or function as a dedicated, specific, and particular machine, for example a word processing machine, a digital image acquisition machine, a media playing machine, a gaming system, a communications device, a smartphone, a neural network, a machine learning model, or similar devices.

The computing device <NUM> may include at least one wireless input/output (I/O) interface <NUM>. The at least one wireless I/O interface <NUM> may be communicably coupled to one or more physical output devices <NUM> (tactile devices, video displays, audio output devices, hardcopy output devices, etc.). The at least one wireless I/O interface <NUM> may communicably couple to one or more physical input devices <NUM> (pointing devices, touchscreens, keyboards, tactile devices, etc.). The at least one wireless I/O interface <NUM> may include any currently available or future developed wireless I/O interface. Example wireless I/O interfaces include, but are not limited to: BLUETOOTH®, near field communication (NFC), and similar.

The computing device <NUM> may include one or more wired input/output (I/O) interfaces <NUM>. The at least one wired I/O interface <NUM> may be communicably coupled to one or more physical output devices <NUM> (tactile devices, video displays, audio output devices, hardcopy output devices, etc.). The at least one wired I/O interface <NUM> may be communicably coupled to one or more physical input devices <NUM> (pointing devices, touchscreens, keyboards, tactile devices, etc.). The wired I/O interface <NUM> may include any currently available or future developed I/O interface. Example wired I/O interfaces include but are not limited to universal serial bus (USB), IEEE <NUM> ("FireWire"), and similar.

The computing device <NUM> may include one or more communicably coupled, non-transitory, storage devices <NUM>. The storage devices <NUM> may include one or more hard disk drives (HDDs) and/or one or more solid-state storage devices (SSDs). The one or more storage devices <NUM> may include any current or future developed storage appliances, network storage devices, and/or systems. Non-limiting examples of such storage devices <NUM> may include, but are not limited to, any current or future developed non-transitory storage appliances or devices, such as one or more magnetic storage devices, one or more optical storage devices, one or more electro-resistive storage devices, one or more molecular storage devices, one or more quantum storage devices, or various combinations thereof. In some implementations, the one or more storage devices <NUM> may include one or more removable storage devices, such as one or more flash drives, flash memories, flash storage units, or similar appliances or devices capable of communicable coupling to and decoupling from the computing device <NUM>.

The one or more storage devices <NUM> may include interfaces or controllers (not shown) communicatively coupling the respective storage device or system to the bus <NUM>. The one or more storage devices <NUM> may store, retain, or otherwise contain machine-readable instruction sets, data structures, program modules, data stores, databases, logical structures, and/or other data useful to the processor cores <NUM> and/or graphics processor circuitry <NUM> and/or one or more applications executed on or by the processor cores <NUM> and/or graphics processor circuitry <NUM>. In some instances, one or more data storage devices <NUM> may be communicably coupled to the processor cores <NUM>, for example via the bus <NUM> or via one or more wired communications interfaces <NUM> (e.g., Universal Serial Bus or USB); one or more wireless communications interface <NUM> (e.g., Bluetooth®, Near Field Communication or NFC); and/or one or more network interfaces <NUM> (IEEE <NUM> or Ethernet, IEEE <NUM>, or Wi-Fi®, etc.).

Machine-readable instruction sets <NUM> and other programs, applications, logic sets, and/or modules may be stored in whole or in part in the system memory <NUM>. Such machine-readable instruction sets <NUM> may be transferred, in whole or in part, from the one or more storage devices <NUM>. The machine-readable instruction sets <NUM> may be loaded, stored, or otherwise retained in system memory <NUM>, in whole or in part, during execution by the processor cores <NUM> and/or graphics processor circuitry <NUM>.

The computing device <NUM> may include power management circuitry <NUM> that controls one or more operational aspects of the energy storage device <NUM>. In embodiments, the energy storage device <NUM> may include one or more primary (i.e., non-rechargeable) or secondary (i.e., rechargeable) batteries or similar energy storage devices. In embodiments, the energy storage device <NUM> may include one or more supercapacitors or ultracapacitors. In embodiments, the power management circuitry <NUM> may alter, adjust, or control the flow of energy from an external power source <NUM> to the energy storage device <NUM> and/or to the computing device <NUM>. The external power source <NUM> may include, but is not limited to, a solar power system, a commercial electric grid, a portable generator, an external energy storage device, or any combination thereof.

For convenience, the processor cores <NUM>, the graphics processor circuitry <NUM>, the wireless I/O interface <NUM>, the wired I/O interface <NUM>, the storage device <NUM>, and the network interface <NUM> are illustrated as communicatively coupled to each other via the bus <NUM>, thereby providing connectivity between the above-described components. In alternative embodiments, the above-described components may be communicatively coupled in a different manner than illustrated in <FIG>. For example, one or more of the above-described components may be directly coupled to other components, or may be coupled to each other, via one or more intermediary components (not shown). In another example, one or more of the above-described components may be integrated into the processor cores <NUM> and/or the graphics processor circuitry <NUM>. In some embodiments, all or a portion of the bus <NUM> may be omitted and the components are coupled directly to each other using suitable wired or wireless connections.

Flow charts representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing computing device <NUM>, for example, are shown in <FIG>. The machine-readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor such as the processor <NUM> shown in the example computing device <NUM> discussed above in connection with <FIG>. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flow charts illustrated in <FIG>, many other methods of implementing the example computing device <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

The machine-readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine-readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers). The machine-readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine-readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement a program such as that described herein.

In another example, the machine-readable instructions may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine-readable instructions may be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine-readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, the disclosed machine-readable instructions and/or corresponding program(s) are intended to encompass such machine-readable instructions and/or program(s) regardless of the particular format or state of the machine-readable instructions and/or program(s) when stored or otherwise at rest or in transit.

The machine-readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine-readable instructions may be represented using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc..

As mentioned above, the example processes of <FIG> may be implemented using executable instructions (e.g., computer and/or machine-readable instructions) stored on a non-transitory computer and/or machine-readable medium such as a hard disk drive, a solid-state storage device (SSD), a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

Claim 1:
An apparatus comprising:
one or more performance monitoring counters (<NUM>); and
a secure group manager (<NUM>) to
receive a request to create a secure counter group from a software, SW, process being executed by a processor (<NUM>), the request including identification of the one or more performance monitoring counters (<NUM>);
determine availability of the one or more performance monitoring counters (<NUM>),
creating the secure counter group, assign the one or more performance monitoring counters (<NUM>) to the secure counter group, and save a public key of the SW process,
when the one or more performance monitoring counters (<NUM>) are available;
receive and save a private key for the secure counter group;
receive a request to configure the secure counter group from the SW process;
verify the configuration using the public key of the SW process; and
start sampling of the one or more performance monitoring counters (<NUM>) when the configuration is verified.