Latest Linux Kernels Fix Security Flaw In The Intel Processors With iGPUs
Linux 5.4.12 as well as updates to the stable branch kernels released on Tuesday have a security patch for Intel processors with Gen9 graphics which addresses a vulnerability that could be used for "information disclosure via local access". Older Intel chips are also affected. The details for CVE-2019-14615 have not been made public.
written by 윤채경 (Yoon Chae-kyung). published 2020-01-15 - last edited 2020-01-17
A message to the "Linux Intel GFX" mailing list describes the vulnerability, known as CVE-2019-14615 in the CVE database and PSIRT-TA-201910-001 in Intel's ID system, as:
"Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access."
and the kernel changelog describes it as:
"Intel GPU Hardware prior to Gen11 does not clear EU state during a context switch. This can result in information leakage between contexts.
For Gen8 and Gen9, hardware provides a mechanism for fast cleardown of the EU state, by issuing a PIPE_CONTROL with bit 27 set. We can use this in a context batch buffer to explicitly cleardown the state on every context switch.
As this workaround is already in place for gen8, we can borrow the code verbatim for Gen9."
Wade Mealing from the Red Hat product security team described the practical implications in redhat bug #1789209:
"How it works:
- - Userspace creates a batchbuffer
- - Batchbuffer sent to kernel via ioctl
- - ioctl (2) issues it as an "Execution Unit" for the hardware.
- - The kernel schedules another process to run.
- - Another process (running as user) can access the previous Execution Unit results by re-using Execution Units results.
A patch which clears the execution state between context switches on gen8 Intel graphics was merged in January 2017 for completely different reasons. The patch for gen9 which was added to the kernel git tree as well as 5.4.12, 4.19.96, 4.14.165, 4.9.210 and 4.4.210 on Tuesday uses the same
gen8_emit_pipe_control function gen8 graphics has used since 2017.
Intel gen8 hardware includes everything from "Broadwell" up to but not including "Skylake". Intel gen9 hardware includes everything from Skylake to Comet Lake. Cannonlake was the entire "gen10". "Icelake" chips are the first gen11 chips.
The older gen7 (Ivy Bridge) and gen7.5 (Haswell) chips are also affected. A patch addressing CVE-2019-14615 on gen7 and gen7.5 hardware was submitted to the "Linux Intel GFX" mailing list on Tuesday. That patch will not be back-ported to older kernels. Intel's reasoning is that it would be mostly pointless to backport a patch which clears EU/L3 resources to older kenels because gen7/gen7.5 driver code lacks address space isolation.
"Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms.
By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.*"
Users of older Intel processors with gen7 and gen7.5 integrated graphics will, in other words, have to live with security vulnerabilities until/unless a future kernel gets a major rewrite which adds address space isolation for those chips. Future kernels will have the patch which clears EU and URB resources prior to context restores - but it will, for now, not provide much in terms of actual security.
Security.. At What Price?
Forcibly clearing the EU/L3 state on each context switch is somewhat expensive. The performance impact with the latest kernel on gen9 hardware is there but the the increased power draw is a bigger concern. Quick absolutely not scientific testing indicates that notebook chips using the latest kernels draw 1-1.5W more power on average. That translates to 10-20% less battery life. On the flip-side: the kernel has been doing this on gen8 hardware for almost three years.
Not A Huge Or Remotely Exploitable Security Problem
There is no need to panic. You can keep calm and Gangnam Style.
Exploring how a security vulnerability can be applied and used in real-world attacks will typically provide some insights into its seriousness. A user-space program running as one user could use this vulnerability to get information from another user-space program. That means that an attacker would have to have a working user account and the ability to install and run code to get anywhere using this vulnerability. That may be a problem if you are providing virtualization services to a diverse customer base (=cloud providers). Very few desktop and laptop owners have random untrusted users logging in and running code on a regular basis.
CVE-2019-14615 is, practically speaking, a non-issue for the vast majority of desktop and laptop users. You may want to upgrade your kernel anyway, more security is always preferable to less security.
Updates kernels are available from kernel.org. Major GNU/Linux distributions will likely ship updated kernels with the security patch for gen9 Intel hardware within a week. The patch for gen7 hardware will not be back-ported, it will only be available in future kernels so distributions won't ship that one any time soon. But won't worry too much if you are using a gen7 or gen7.5 Intel chip; you are probably not using it to provide cloud services with GPU virtualization.