Messages in this thread | | | Date | Tue, 21 Jan 2020 17:14:12 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH RFC] x86/speculation: Clarify Spectre-v2 mitigation when STIBP/IBPB features are unsupported |
| |
On Tue, Jan 21, 2020 at 05:02:57PM +0100, Vitaly Kuznetsov wrote: > When STIBP/IBPB features are not supported (no microcode update, > AWS/Azure/... instances deliberately hiding SPEC_CTRL for performance > reasons,...) /sys/devices/system/cpu/vulnerabilities/spectre_v2 looks like > > Mitigation: Full generic retpoline, STIBP: disabled, RSB filling > > and this looks imperfect. In particular, STIBP is 'disabled' and 'IBPB' > is not mentioned while both features are just not supported. Also, for > STIBP the 'disabled' state (SPECTRE_V2_USER_NONE) can represent both > the absence of hardware support and deliberate user's choice > (spectre_v2_user=off) > > Make the following adjustments: > - Output 'unsupported' for both STIBP/IBPB when there's no support in > hardware. > - Output 'unneeded' for STIBP when SMT is disabled/missing (and this > switch_to_cond_stibp is off). > > RFC. Some tools out there may be looking at this information so by > changing the output we're breaking them. Also, it may make sense to > separate kernel and userspace protections and switch to something like > > Mitigation: Kernel: Full generic retpoline, RSB filling; Userspace: > Vulnerable > > for the above mentioned case. > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> > --- > Documentation/admin-guide/hw-vuln/spectre.rst | 3 +++ > arch/x86/kernel/cpu/bugs.c | 9 +++++++-- > 2 files changed, 10 insertions(+), 2 deletions(-)
There's another attempt to fix similar aspects of this whole deal going on ATM:
https://lkml.kernel.org/r/20191229164830.62144-1-asteinhauser@google.com
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |