Running Average Power Limit Energy Reporting / CVE-2020-8694 , CVE-2020-8695 / INTEL-SA-00389

Disclosure date:  2020-11-10 Published date:  2022-02-08

Severity rating:  5.6 Medium

Industry-wide severity ratings can be found in the National Vulnerability Database

Aliases

• Platypus

Related Content

INTEL-SA-00389

CVE-2020-8694

CVE-2020-8695

Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations

Security Best Practices for Side Channel Resistance

Overview

Most modern processors, including Intel processors, provide Running Average Power Limit (RAPL) interfaces for reporting the accumulated energy consumption of various power domains (for example, PP0¹ or Package). Under certain conditions, observable RAPL energy² reporting may unintentionally allow information about the system to be inferred. This issue has been assigned CVE-2020-8695 CVSS Score: 5.3 Medium and CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N. A corresponding issue of allowing an authenticated unprivileged user to access to these interfaces has been assigned CVE-2020-8694 with CVSS 5.6 Medium and CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N.

When a CPU processes data, transistors are switched on and off depending on the data being processed. Since switching transistors uses a tiny bit of energy, there is some correlation between energy consumption and the data being processed. This physical property may lead to malicious actors correlating the system’s reported energy consumption with possible secret data being processed on the system. By performing power analysis, an adversary might be able to retrieve secret data, such as cryptographic keys across trust boundaries. 

Different attack scenarios are possible depending on what access privileges the adversary has and what the trust boundary of the victim is. Cases include an unprivileged adversary attacking a privileged or unprivileged application, or an adversary attacking a secure enclave (for example, Intel® Software Guard Extensions (Intel® SGX)). 

There are currently no explicit use cases for unprivileged software to access RAPL interfaces, thus the mitigation for this issue is to not expose RAPL interfaces to unprivileged applications, as in CVE-2020-8694. For the scenario that a privileged adversary attacks an Intel® SGX enclave, the mitigation is to change the method in which energy consumption is reported when Intel SGX is enabled, as in CVE-2020-8695. This reduces the correlation between the energy consumption reporting and the victim program/data.

We note that RAPL interfaces have a limited sampling rate, low sampling frequency, and low resolution, which make most attacks using these methods difficult and time consuming.  Nevertheless, Intel recommends system administrators apply both patches to their systems:

1. The Linux* patch to their Linux systems, and
2. The microcode patch to all systems with Intel SGX enabled.

The mitigation outlined in this paper will be delivered as part of IPU 2021.2 and will supplant the mitigation delivered in IPU 2020.2.  Intel recommends system administrators update their systems with the latest microcode. For a comparison of the two mitigations, refer to the Revised Energy Reporting in IPU 2021.2 and IPU 2020.2 Energy Reporting Solution sections.

RAPL Energy Reporting Use Cases

RAPL is an interface for reporting accumulated energy consumption of various system-on-chip (SoC) power domains. The RAPL energy reporting feature has been available for many generations on Intel SoC products, and energy reporting is standard practice for the industry. Intel processors utilize this energy information for internal SoC management purposes, such as control of SoC power limits in association with Intel® Turbo Boost Technology power limit settings within the SoC. This RAPL energy data is exposed to the platform via the host-software-accessible model specific registers (MSRs) MSR_PKG_Energy_Status³ and MSR_PP0_Energy_Status⁴. This allows software to use the RAPL energy data for observation, telemetry, and/or inputs to platform-level power or thermal control algorithms. Energy information from the RAPL interface gets updated every ~1 ms, which is several orders of magnitude slower than what physical side channel probing could achieve.

Certain privileged software utilities may perform platform power and thermal management at runtime. Such software may use energy information from RAPL to tune system performance or track power usage. In server systems, the energy data is sometimes used to perform rack-level power management and efficiency loading between systems. Some operating systems have thermal daemon software to manage SoC thermals that read energy information from the RAPL interface during thermal events. Other thermal management software, such as Intel® Dynamic Tuning Technology (Intel® DTT) software, also reads energy information from the RAPL interface. The microcode patches to mitigate this issue impact the behavior of RAPL energy reporting and thus the behavior of such management software.

It is difficult to determine how many applications use SoC energy information from the RAPL interface. Intel is aware of several applications, including hardware observation tools such as Hwinfo64 or CPU-Z, that may support reporting SoC energy information from the RAPL interface. Similar tools exist in closed- or open-source operating systems for observing the RAPL energy data. After applying the mitigations, users who track energy data using these tools could observe differences in energy reporting with Intel SGX on compared to if Intel SGX is off.

Scenarios

There are several different possible attack scenarios using this method. We can categorize these scenarios based on the different privileges of the adversary and the trust boundary of the victim:

1. Unprivileged adversary attacks unprivileged victim: A malicious user application may use RAPL to infer confidential information of another unprivileged application running on the same or a different CPU core by observing the power-related behavior of the victim application.  
2. Unprivileged adversary attacks privileged victim: A malicious unprivileged application may use RAPL to infer information being processed by the kernel.
3. Adversary attacks Trusted Execution Environment: The RAPL side channel attack provides a means for an attack to occur on Intel SGX. An Intel SGX enclave is used as a means to provide a secure execution environment for applications that use encryption keys, passwords, digital rights management (DRM) technology, and secure remote computation. Intel SGX allows this secret data to be used in a fortified container known as an enclave. An attack using energy information from RAPL may extract secrets from the enclave.

Mitigation and its Effect

As a general rule, the attack scenarios from malicious unprivileged applications to other trust domains can be blocked by removing user-level read access to the MSRs. Hypervisors may choose to remove access to these MSRs for untrusted guests.  Removing this access eliminates the most common avenues of accessing energy information from RAPL on the system. Refer to Appendix: CVE-2020-8694 for more information.

For processors affected by CVE-2020-8695, Intel has released a microcode patch that modifies the energy information reported by RAPL when Intel SGX is enabled or when system software enables this feature by using a new architectural MSR feature. Intel recommends using the FIT Microcode Update mechanism described in the Microcode Update Guidance to apply the latest microcode update. 

This mitigation implementation alters the internal RAPL energy reporting calculation algorithm and filters the energy information as compared to the previous legacy power reporting method. This will impact the energy information from RAPL that any software reading the RAPL MSRs will observe. Refer to Figure 1 below.  

The IPU 2021.2 RAPL filtering method has been changed compared to the RAPL filtering method introduced in IPU 2020.2. The new IPU 2021.2 method uses a combination of random energy noise and a change to energy update frequency to mitigate the attack.  This newer method should create a smaller delta in reported power between power readings taken with the filtering disabled compared to when the filtering is enabled. 

• When Intel SGX is disabled or system software has not enabled the filtering: Legacy energy information is reported, which is called unfiltered. 
  • Energy information is measured by the SoC voltage regulator along with some calculated energy of unmonitored power domains. Typical energy reporting variation at high power, such as the SoC’s Thermal Design Power (TDP), is ~ 5-10%, but this depends on the OEM design and the calibration of the power monitoring circuit, which is board-design specific.  
• When Intel SGX is enabled or system software has enabled RAPL filtering⁵: energy with mitigation applied is reported, which is called filtered.
  • The filtered RAPL energy value will be visible to privileged software that reads MSR_PKG_Energy_Status and MSR_PP0_Energy_Status using the RDMSR instruction. RDMSR is asynchronous to internal RAPL energy reporting updates. RDMSR only captures snapshots from the latest energy information from RAPL and will not trigger new updates. The frequency that RAPL energy information is updated remains the same at ~1ms.   
  • Note that the internal SOC power control continues to use the unfiltered RAPL energy value. Thus, hardware power management features such as Intel® Turbo Boost Technology will be unchanged by this mitigation.  

Security Improvement from the Mitigation

When the filtered energy reporting is enabled, correlation between the data being used by a program  and its energy reporting is largely reduced, if there is any. For example, assume unfiltered RAPL reports energy consumption of 169J and 171J when executing a program with data A and B, respectively. An adversary may deduce which data is used from the unfiltered energy reporting. Instead of that, the filtered energy reporting may randomly report energy consumption of the program ranging from 165J to 185J regardless of what data is being used. Therefore, it is much harder to infer secret data based on energy reporting.

Energy Reporting Impact of the Mitigation

The RAPL filtering mechanism has been updated over time. Refer to the Energy Reporting Solution released in IPU 2020.2 for details on the original mitigation mechanism

Revised Energy Reporting in IPU 2021.2

IPU 2021.2 introduces a revised RAPL filtering mechanism which replaces the existing filtering mechanism introduced in IPU 2020.2. This new mechanism helps mitigate attacks by introducing random energy noise and changing the frequency of the energy reporting. These changes reduce the observed difference in power when comparing filtered power reporting with unfiltered power reporting, and also helps reduce power delta variations observed in the previous release. Software can sample energy status at arbitrary frequency through reading the MSRs. When comparing filtered vs. unfiltered RAPL power using this new mechanism, readings at 1 second intervals will show the delta as typically less than 2% standard deviation. At shorter time intervals of 100ms, the observed delta will grow to between 5-15%. 

Optional Software Switch

Intel products provide an opt-in software switch that allows system software to enable RAPL power filtering to protect against issues similar CVE-2020-8965. This is a one-way switch and cannot be disabled without a reboot. 
Support for this new feature is exposed via a software-enumerated MSR described in the Enumeration and Architectural MSRs section below.

Once software identifies that hardware supports IA32_ARCH_CAPABILITIES, then software can opt-in to enabling the RAPL filtering via IA32_MISC_PACKAGE_CTLS. 

Details regarding these two registers are below and will be added to the Intel® 64 and IA-32 Architecture Software Developer’s Manual Volume 4 at a later date. 

In most cases, any attempt to enable Intel SGX will auto-enable RAPL power filtering. Refer to the limitations described in the IA32_MISC_PACKAGE_CTLS MSR section.

Enumeration and Architectural MSRs

The IA32_ARCH_CAPABILITIES MSR (index 10AH) enumerates support for the RAPL mitigation mechanism. This is a read-only MSR that is supported if CPUID.(EAX=7H,ECX=0):EDX[29] is enumerated as 1. 

The new IA32_ARCH_CAPABILITIES[10] bit enumerates support for IA32_MISC_PACKAGE_CTLS MSR. 

The new IA32_ARCH_CAPABILITIES[11] bit enumerates support for filtering RAPL MSRs-reported processor power consumption data. Processors that set this bit support the IA32_MISC_PACKAGE_CTLS MSR and allow software to set and read IA32_MISC_PACKAGE_CTLS[0] (ENERGY_FILTERING_ENABLE) bit. 

Processors that don’t enumerate IA32_ARCH_CAPABILITIES MSR support also don’t support IA32_MISC_PACKAGE_CTLS MSR and don’t support filtering RAPL MSRs-reported processor power consumption data.

Note: The mitigation mechanisms (including IA32_ARCH_CAPABILITIES MSR support) may be introduced to a processor by loading a microcode update. In such cases, software should re-evaluate the enumeration after loading that microcode update.

The table above is not intended to provide full details of the IA32_ARCH_CAPABILITIES MSR; see the Intel® 64 and IA-32 Architecture Software Developer’s Manual, Volume 4 (Model-Specific Registers) for full details.

IA32_MISC_PACKAGE_CTLS MSR

The IA32_MISC_PACKAGE_CTLS MSR bits are defined as processor package scope. 

This MSR has a value of 0 after reset and is unaffected by INIT# or SIPI#.

The ENERGY_FILTER_ENABLE bit can be changed from 0 to 1 but cannot be changed from 1 to 0. After setting, all attempts to clear it are ignored until the next processor reset.
Environments that are concerned about software-based power side channels may wish to set ENERGY_FILTERING_ENABLE in order to apply filtering to the processor power consumption data. 

Limitations: 

• On some processor implementations, ENERGY_FILTERING_ENABLE bit may be internally set by the CPU during the processor’s boot flow to protect Intel SGX. This also applies to cases when the mitigation mechanisms are introduced to a processor by loading a microcode update.
• Some processors implementations may not signal #GP fault on attempts to set reserved bits in the IA32_MISC_PACKAGE_CTLS MSR. It is recommended always set reserved bits to 0’s
• On some processor implementations, only when the mitigation mechanisms are introduced to a processor by loading a microcode update, setting ENERGY_FILTERING_ENABLE bit may be ignored even if it is enumerated as supported. In such cases, Intel recommends contacting the OEM for updated BIOS. Intel recommends software to always verify whether an attempt to set the ENERGY_FILTERING_ENABLE bit was successful using the RDMSR(IA32_MISC_PACKAGE_CTLS) instruction and checking the ENERGY_FILTERING_ENABLE bit value. 

Affected Processors

All processors supporting RAPL are impacted by CVE-2020-8694 and should apply the migration in the Appendix: CVE-2020-8694 section.

All processors supporting RAPL plus Intel SGX are impacted by CVE-2020-8695, and should apply the microcode patch. This patch needs to be loaded from FIT to be effective.

Appendix: CVE-2020-8694

CVE-2020-8694 has resulted in a change in the Linux powercap driver. Since Linux v3.13, released in 2013, the Linux intel_powercap driver has the ability to expose the RAPL hardware energy counters to applications. If the kernel is built with CONFIG_INTEL_RAPL enabled, the RAPL interface is exposed to applications.

 The API is visible in /sys/class/powercap/intel-rapl*/*/energy_uj.

These sysfs attributes, by default, are readable by any user logged into the machine. 

The Linux mitigation for this issue is to remove user access to these attributes.

Patch 949dd0104c49 (“powercap: restrict energy meter to root access”), in Linux kernel 5.10.0-rc4, changes the default permissions on these attributes such that only the system administrator (root account) can access these attributes.

This allows services, such as thermald, to continue functioning, as they run as root.

Note that third-party applications that also access these attributes must also run as root to continue reading them.

The patch simply changes the default permissions on the sysfs attributes. System administrators can do this manually on systems that do not yet have this patch by using the following command:

$ sudo chmod 400 /sys/class/powercap/intel-rapl*/*/energy_uj

Appendix: IPU 2020.2 Energy Reporting Solution

The differences between filtered energy reporting when Intel SGX is enabled compared to unfiltered energy reporting will vary depending on many factors. When comparing filtered energy reporting to unfiltered energy reporting with measurements taken at 1 second intervals, the power delta can be between 0-50%, but the exact delta cannot be guaranteed. Many factors can affect the power delta, including:

• SoC power
• Temperature
• Device transistor leakage (CDYN)
• Different applications or workloads
• The mix of instructions that are executed
• Number of active cores
• Overall SoC core count
• SKU (for example, Intel® Core™ i3, i5, or i7 processors)
• Hyperthreading support
• Various other SoC features

The table below summarizes differences between the IPU 2020.2 and IPU 2021.2 mitigations.

Appendix: Related Technology

Intel® Trust Domain Extensions (Intel® TDX) for virtual machine (VM) isolation is used in conjunction with Intel SGX and uses RAPL filtered energy information.

Intel is continuously improving its filtered energy information from RAPL to further reduce correlation with operand values, and may introduce a mixture of random noises, quantization, rate changes, etc. in the future.
 

Footnotes

1. PP0 is a power plane for the Intel® architecture core, and Package includes all power planes.
2. Power P = Energy E/ time t
   RAPL power information and RAPL energy reporting are used interchangeably.
3. Address 0x611, may vary by processor model.
4. Address 0x639, may vary by processor model.
5. BIOS might allow for two modes for Intel SGX to be enabled: 
   1: Software enabled by the user and a reboot is required. 
   2: Intel SGX is enabled in BIOS and Intel SGX is always on.
6. Assuming the data doesn’t affect timing. Refer to Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations.

Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources