Project

General

Profile

Actions

Bug #13383

closed

generalize check for serializing LFENCE

Added by Patrick Mooney 5 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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

Related to illumos gate - Bug #13387: bhyve should expose lfence serialize in DE_CFG MSRClosedPatrick Mooney

Actions
Related to illumos gate - Bug #13384: tsc_read() should use lfence when prudentClosedPatrick Mooney

Actions
Actions #1

Updated by Patrick Mooney 5 months ago

  • Related to Bug #13387: bhyve should expose lfence serialize in DE_CFG MSR added
Actions #2

Updated by Patrick Mooney 5 months ago

  • Related to Bug #13384: tsc_read() should use lfence when prudent added
Actions #3

Updated by Electric Monk 5 months ago

  • Gerrit CR set to 1112
Actions #4

Updated by Patrick Mooney 4 months 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.

Actions #5

Updated by Patrick Mooney 4 months 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).

Actions #6

Updated by Patrick Mooney 4 months 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.

Actions #7

Updated by Electric Monk 4 months 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>

Actions

Also available in: Atom PDF