L1TF Cache Flushing Mode Could Soon Be Controlled Via Kconfig Build Option

Approaching the two year anniversary next month of the L1TF / Foreshadow vulnerability, a Google engineer has proposed allowing the default mitigation state to be controlled via a Kconfig build-time option.

This speculative execution attack on Intel CPUs has been mitigated since August 2018 and has offered for KVM virtual machine mitigation the kvm-intel.vmentry_l1d_flush module parameter for controlling the L1 data cache flushing behavior. But now a Google engineer has proposed setting the default L1 data flushing mode to be configurable at build-time via a new KVM_VMENTRY_L1D_FLUSH knob. This knob doesn't provide any new L1 Terminal Fault mitigation but rather just allows adjusting the default behavior for the default configuration of that kernel image, whether it be to never flush the cache before a VMENTER, conditionally flush, or the most impactful state of always flushing.

The existing default behavior of the Linux kernel is for flushing in specific/conditional instances when the host enters the guest, due to the performance costs involved. With this Kconfig option, distributions could ship kernels where the flushing always happens (the most severe for performance) or never (better performance, albeit security risks of L1TF). This simply makes it easier to define the default than the vmentry_l1d_flush module parameter for KVM. This new Kconfig option doesn't touch the Hyper Threading behavior.

The patch is quite straightforward so could see it quite possibly for Linux 5.9. We'll see and if any distribution vendors ahead end up making use of KVM_VMENTRY_L1D_FLUSH's different defaults. Given a Google engineer is working on it, they could be quite likely considering changing the default for their cloud or other internal needs.