Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables
The recent speculative execution CVEs address three potential attacks across a wide variety of processor architectures and platforms, each requiring slightly different fixes. In many cases, these fixes also require microcode updates from the hardware vendors.
Red Hat has made updated kernels available to address these security vulnerabilities. These patches are enabled by default (detailed below), because Red Hat prioritizes out of the box security. Speculative execution is a performance optimization technique. Thus, these updates (both kernel and microcode) may result in workload-specific performance degradation. Therefore, some customers who feel confident that their systems are well protected by other means (such as physical isolation), may wish to disable some or all of these kernel patches. If the end user elects to enable the patches in the interest of security, this article provides a mechanism to conduct performance characterizations with and without the fixes enabled.
Overview
Red Hat Customer Portal Labs provides a Spectre And Meltdown Detector to help you detect if your systems are vulnerable to these CVEs.
The recent speculative execution CVEs address three potential attacks across a wide variety of processor architectures and platforms, each requiring slightly different fixes. In many cases, these fixes also require microcode updates from the hardware vendors.
Red Hat has made updated kernels available to address these security vulnerabilities. These patches are enabled by default (detailed below), because Red Hat prioritizes out-of-the-box security. Speculative execution is a performance-optimization technique, thus, these updates (both kernel and microcode) may result in workload-specific performance degradation. Therefore, some customers who feel confident that their systems are well protected by other means (such as physical isolation and strong access controls/monitoring), may wish to disable some or all of these kernel patches. If the end user elects to enable the patches in the interest of security, this article provides a mechanism to conduct performance characterizations with and without the fixes enabled.
The security vulnerabilities described in these three CVEs may be found in modern microprocessors and operating systems on major hardware platforms including x86 (Intel and AMD chipsets), System Z, Power, and ARM. For Red Hat Enterprise Linux kernels, three debugfs tunables control the behavior of the various patches in the updated kernel, working in cooperation with the microcode, where supplied.
These three debugfs tunables can be enabled or disabled on the kernel command line at boot, or at runtime via debugfs controls. The tunables control Page Table Isolation (pti), Indirect Branch Restricted Speculation (ibrs), and Indirect Branch Prediction Barriers (ibpb). Red Hat enables each of these features by default as needed to protect the architecture detected at boot.
For those wanting to disable the fixes for these CVEs to recover the performance loss, two options are available:
Persistently disable – Effective across a reboot
The first option is to disable them via the kernel command line by adding these flags, then reboot the kernel to have them take effect:
noibrs noibpb nopti
Note: you can individually disable each parameter, for performance characterization it is not required that all 3 be simultaneously disabled.
Runtime disable – Does not persist through a reboot
The second option is to disable them at runtime with the following three commands. The change is immediately active and does not require a reboot.
# echo 0 > /sys/kernel/debug/x86/pti_enabled
# echo 0 > /sys/kernel/debug/x86/ibpb_enabled
# echo 0 > /sys/kernel/debug/x86/ibrs_enabled
Note this requires that the debugfs filesystem be mounted. In RHEL 7 the debugfs is mounted by default. In RHEL 6 you can mount it manually with
mount -t debugfs nodev /sys/kernel/debug
Verifying changes
To verify the fixes for these CVEs are correctly disabled, cat the following three files to verify their values are all set to 0.
# cat /sys/kernel/debug/x86/pti_enabled
# cat /sys/kernel/debug/x86/ibpb_enabled
# cat /sys/kernel/debug/x86/ibrs_enabled
Some applications may still see up to a 2% performance loss even with the above CVE flags set to 0.
Details:
The rest of this article describes more specifics about each CVE variant.
CVE-2017-5753 (variant #1/Spectre) is a Bounds-checking exploit during branching. This issue is fixed with a kernel patch. Variant #1 protection is always enabled; it is not possible to disable the patches. Red Hat’s performance testing for variant #1 did not show any measurable impact.
CVE-2017-5715 (variant #2/Spectre) is an indirect branching poisoning attack that can lead to data leakage. This attack allows for a virtualized guest to read memory from the host system. This issue is corrected with microcode, along with kernel and virtualization updates to both guest and host virtualization software. This vulnerability requires both updated microcode and kernel patches. Variant #2 behavior is controlled by the ibrs and ibpb tunables (noibrs/ibrs_enabled and noibpb/ibpb_enabled), which work in conjunction with the microcode.
CVE-2017-5754 (variant #3/Meltdown) is an exploit that uses speculative cache loading to allow a local attacker to be able to read the contents of memory. This issue is corrected with kernel patches. Variant #3 behavior is controlled by the pti tunable (nopti/pti_enabled).
As noted, installing the microcode update for your hardware, if provided by the hardware vendor, is necessary to protect against variant 2. Please contact your hardware vendor for microcode updates.
Page Table Isolation (pti)
“nopti”/pti_enabled controls the Kernel Page Table Isolation feature,which isolates kernel pagetables when running in userland. This feature addresses CVE-2017-5754, also called variant #3, or Meltdown.
Customers and vendors can disable the PTI feature by passing “nopti” to the kernel command line at boot, or dynamically with the runtime debugfs control below:
# echo 0 > /sys/kernel/debug/x86/pti_enabled
Indirect Branch Restricted Speculation (ibrs)
“noibrs”/ibrs_enabled controls the IBRS feature in the SPEC_CTRL model-specific register (MSR) when SPEC_CTRL is present in cpuid (post microcode update). When ibrs_enabled is set to 1 the kernel runs with indirect branch restricted speculation, which protects the kernel space from attacks (even from hyperthreading/simultaneous multi-threading attacks). When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2.
Customer and vendors can disable the ibrs implementation in microcode by passing “noibrs” to the kernel command line at boot, or dynamically with the debugfs control below:
# echo 0 > /sys/kernel/debug/x86/ibrs_enabled
Indirect Branch Prediction Barriers (ibpb)
“noibpb”/ibpb_enabled controls the IBPB feature in the PRED_CMD model-specific register (MSR) if either IBPB_SUPPORT or SPEC_CTRL is present in cpuid (post microcode update). When ibpb_enabled is set to 1, an IBPB barrier that flushes the contents of the indirect branch prediction is run across user mode or guest mode context switches to prevent user and guest mode from attacking other applications or virtual machines on the same host. In order to protect virtual machines from other virtual machines, ibpb_enabled=1 is needed even if ibrs_enabled is set to 2. If ibpb_enabled is set to 2, indirect branch prediction barriers are used instead of IBRS at all kernel and hypervisor entry points (in fact, this setting also forces ibrs_enabled to 0). ibpb_enabled=2 is the default on CPUs that don’t have the SPEC_CTRL feature but only IBPB_SUPPORT. ibpb_enabled=2 doesn’t protect the kernel against attacks based on simultaneous multi-threading (SMT, also known as hyperthreading); therefore, ibpb_enabled=2 provides less complete protection unless SMT is also disabled. This feature addresses CVE-2017-5715, variant #2.
Customer and vendors can disable the ibpb implementation in microcode by passing “noibpb” to the kernel command line at boot, or dynamically with the debugfs control below:
# echo 0 > /sys/kernel/debug/x86/ibpb_enabled
Architectural Defaults
By default, each of the 3 tunables that apply to an architecture will be enabled automatically at boot time, based upon the architecture detected.
Intel Defaults:
pti 1 ibrs 1 ibpb 1 -> fix variant#1 #2 #3
pti 1 ibrs 0 ibpb 0 -> fix variant#1 #3 (for older Intel systems with no microcode update available)
AMD Defaults:
Due to the differences in underlying hardware implementation, AMD X86 systems are not vulnerable to variant #3. The correct default values will be set on AMD hardware based on dynamic checks during the boot sequence.
pti 0 ibrs 0 ibpb 2 -> fix variant #1 #2 if the microcode update is applied
pti 0 ibrs 2 ibpb 1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates
via:https://access.redhat.com/articles/3311301
