linux-kernel - Re: [PATCH RFC] x86/speculation: Clarify Spectre-v2 mitigation when STIBP/IBPB features are unsupported

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 21 Jan 2020 17:37:49 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Waiman Long <longman@...hat.com>, x86@...nel.org
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Tyler Hicks <tyhicks@...onical.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH RFC] x86/speculation: Clarify Spectre-v2 mitigation when STIBP/IBPB features are unsupported

Waiman Long <longman@...hat.com> writes:

> On 1/21/20 11:02 AM, 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).
>
> I support outputting "unsupported" when the microcode doesn't support
> it. However, I am not sure if "unneeded" is really necessary or not.
> STIBP is not needed when SMT is disabled or when Enhanced IBRS is
> available and used. Your patch handles the first case, but not the
> second. I think it may be easier to just leave it out in case it is not
> needed.

Makes sense. Or, alternatively, we can output 'unneeded' in both cases
to make things explicit and  to distinguish it from the current state of
IBPB where missing means 'unsupported by hardware'.

-- 
Vitaly