Open knweiss opened 6 years ago
AFAICS this is the explanation why RSB fill should be enabled unconditionally on all Spectre v2 vulnerable CPUs. Quote:
* If spectre v2 protection has been enabled, unconditionally fill
* RSB during a context switch; this protects against two independent
* issues:
*
* - RSB underflow (and switch to BTB) on Skylake+
* - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
However, strictly speaking this fixes the SpectreRSB variant of Spectre v2, doesn't it? Shouldn't this be handled as an separately issue? (See #224)
Also, please notice this Red Hat bugzilla comment on bz1616245:
This issue does not affect the versions of the kernel package as shipped with
Red Hat Enterprise Linux 5, 6, 7 and Red Hat Enterprise MRG 2.
However, spectre-meltdown-checker
on RHEL 7.5 reports the kernel as vulnerable.
On the same bz new comment explains why RHEL6/7 kernels are not affected by SpectreRSB. Comment #8.
Seems like Red Hat is claiming their kernels have been doing this for longer than the upstream patch. They don't seem to be using X86_FEATURE_RSB_CTXSW, or priting any relevant output during boot, though?
Is this even fixable? It would probably mean white-listing RHEL's default combination of mitigiations, somehow?
The following system with Broadwell CPU uses the Red Hat/CentOS 7.5 defaults regarding Spectre mitigation. (FWIW: This is a virtual machine!)
Unfortunately,
spectre-meltdown-checker
and Red Hat's sysfs status disagree about the mitigation status of Spectre Variant 2:spectre-meltdown-checker says this:
Red Hat's sysfs file:
Red Hat's mitigation defaults are described here and the defaults for this pre-Skylake CPU with updated microcode are:
However,
spectre-meltdown-checker
(commit dd67fd9) complains about the disabled IBRS:spectre-metldown-checker
is right and Red Hat is wrong?Side note: There's a small typo in the
VULNERABLE
line: "RSB filling", not "RBS filling".