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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20c1c0f2-046e-eb77-d655-75f62ebafcb2@redhat.com>
Date:   Tue, 21 Jan 2020 11:22:44 -0500
From:   Waiman Long <longman@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...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

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.

Cheers,
Longman