Bug #13383
closed
generalize check for serializing LFENCE
100%
Description
As part of the Spectre retpoline logic, AMD chips are checked for whether their LFENCE instruction is serializing. This includes attempting to set a bit to enable that behavior in the DE_CFG MSR on newer (families 0x10 and >= 0x12). A serializing LFENCE is also useful for rdtsc, where it's preferable to using CPUID for that purpose. It would probably make sense to follow Linux's lead, and add an x86feature for serializing LFENCE, so it can be checked (and/or enabled) in one place, and then both retpoline and tsc_read_patch() consumers can make use of it.
A more accurate check for serializing LFENCE will help us inside hypervisors which do not expose RDTSCP to the guest. Until now, newer AMD chips were assumed not to have serializing LFENCE and would fall back to the much slower (VM exit inducing) CPUID serialization.
Related issues
Updated by Patrick Mooney over 2 years ago
- Related to Bug #13387: bhyve should expose lfence serialize in DE_CFG MSR added
Updated by Patrick Mooney over 2 years ago
- Related to Bug #13384: tsc_read() should use lfence when prudent added
Updated by Patrick Mooney over 2 years ago
I first tested this on modern AMD hardware. Without the change, it was properly detecting and enabling LFENCE serialization (as evidenced by x86_spectrev2_mitigation being set to the RETPOLINE_AMD type. With the change in place, the spectre mitigation was similarly configured, but the serializing lfence x86 feature was also noted as present.
Updated by Patrick Mooney over 2 years ago
I repeated the test in a bhyve guest on that same AMD hardware. Prior to the change on the host (and the guest), the guest reported using the "vanilla" retpoline mitigation. With the fix in place on the host, the guest was then using the AMD-specific retpoline, since it observed the configurable lfence serialization. With the fix also in place on the guest, the tsc_type changed from 0x1 (TSC_RDTSC_CPUID) to 0x3 (TSC_RDTSC_LFENCE).
Updated by Patrick Mooney over 2 years ago
I repeated that test procedure on an Intel machine with an illumos guest. I confirmed that the lfence serialization detection did not change (it was already working properly). The combinations of host and guest OS (with/without the patch) all ran as expected.
Updated by Electric Monk over 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit beed421eff10640141fe8f9da29a5c8033a97f52
commit beed421eff10640141fe8f9da29a5c8033a97f52
Author: Patrick Mooney <pmooney@pfmooney.com>
Date: 2021-01-26T21:27:49.000Z
13383 generalize check for serializing LFENCE
13384 tsc_read() should use lfence when prudent
13387 bhyve should expose lfence serialize in DE_CFG MSR
Reviewed by: Robert Mustacchi <rm@fingolfin.org>
Approved by: Dan McDonald <danmcd@joyent.com>