linux-kernel - Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 5 Aug 2022 12:04:34 -0500
From:   Kim Phillips <kim.phillips@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, peterz@...radead.org, bpf@...r.kernel.org,
        jpoimboe@...hat.com, andrew.cooper3@...rix.com,
        linux-kernel@...r.kernel.org, thomas.lendacky@....com
Subject: Re: [PATCH] x86/bugs: Enable STIBP for IBPB mitigated RetBleed

On 8/5/22 9:42 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2022 at 02:22:01PM -0500, Kim Phillips wrote:
>> For retbleed=ibpb, force STIBP on machines that have it,
> 
> Because?

See "6.1.2 IBPB On Privileged Mode Entry / SMT Safety":

https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion_v7_20220712.pdf

Did you want me to re-quote the whitepaper, or reference it,
or paraphrase it, or...?

>> and report its SMT vulnerability status accordingly.
>>
>> Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
>> Signed-off-by: Kim Phillips <kim.phillips@....com>
>> ---
>>   Documentation/admin-guide/kernel-parameters.txt |  4 +++-
>>   arch/x86/kernel/cpu/bugs.c                      | 10 ++++++----
>>   2 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 597ac77b541c..127fa4328360 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -5212,10 +5212,12 @@
>>   			ibpb	     - mitigate short speculation windows on
>>   				       basic block boundaries too. Safe, highest
>>   				       perf impact.
> 
> You should put some blurb here about STIBP and why it is being enabled,
> where present.

unret didn't have it, was just copying unret's entry, but,
ok, will do for both now.

How about:

"{unret,ibpb} alone does not stop sibling threads influencing the predictions of
other sibling threads.  For that reason, we use STIBP on processors that support
it, and mitigate SMT on processors that don't."

>> @@ -2346,10 +2347,11 @@ static ssize_t srbds_show_state(char *buf)
>>   
>>   static ssize_t retbleed_show_state(char *buf)
>>   {
>> -	if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET) {
>> +	if (retbleed_mitigation == RETBLEED_MITIGATION_UNRET ||
>> +	    retbleed_mitigation == RETBLEED_MITIGATION_IBPB) {
>>   	    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
>>   		boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
>> -		    return sprintf(buf, "Vulnerable: untrained return thunk on non-Zen uarch\n");
>> +		    return sprintf(buf, "Vulnerable: untrained return thunk / IBPB on non-AMD based uarch\n");
> 
> Well, you can't lump those together.
>  > You can't especially say "Vulnerable" and "IBPB" in one line.
> 
> To quote from the BTC paper:
> 
> "Software may choose to perform an IBPB command on entry into privileged
> code in order to avoid any previous branch prediction information from
> subsequently being used. This effectively mitigates all forms of BTC for
> scenarios like user-to-supervisor or VM-to-hypervisor attacks."
> 
> Especially if we disable SMT only on !STIBP parts:
> 
>          if (mitigate_smt && !boot_cpu_has(X86_FEATURE_STIBP) &&
>              (retbleed_nosmt || cpu_mitigations_auto_nosmt()))
>                  cpu_smt_disable(false);
> 
> If there are AMD parts which have IBPB but DO NOT have STIBP, then you
> can say "Vulnerable... IBPB" but then you need to check for !STIBP and
> issue that on a separate line.
> 
> I'd say...

Those messages only get printed on non-AMD hardware?

Kim