linux-kernel - Re: [PATCH] x86/srso: Correct the mitigation status when SMT is disabled

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: <20230815201753.GGZNvdcbPHXtEXn4As@fat_crate.local>
Date:   Tue, 15 Aug 2023 22:17:53 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Josh Poimboeuf <jpoimboe@...nel.org>
Cc:     Nikolay Borisov <nik.borisov@...e.com>, X86 ML <x86@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/srso: Correct the mitigation status when SMT is
 disabled

On Tue, Aug 15, 2023 at 12:58:31PM -0700, Josh Poimboeuf wrote:
> AFAICT, nowhere in the spec does it say the SRSO_NO bit won't get set by
> future (fixed) HW.  In fact I'd expect it will, similar to other *_NO
> flags.

I'm pretty sure it won't.

SRSO_NO is synthesized by the hypervisor *software*. Nothing else.

It is there so that you don't check microcode version in the guest which
is nearly impossible anyway.

> Regardless, here SRSO_NO seems to mean two different things: "reported
> safe by host (or HW)" and "not reported safe on Zen1/2 with SMT not
> possible".

Huh?

> Also, in this code, the SRSO_NO+SMT combo doesn't seem logically
> possible, as srso_show_state() only gets called if X86_BUG_SRSO is set,
> which only happens if SRSO_NO is not set by the HW/host in the first
> place.  So here, if boot_cpu_has(X86_FEATURE_SRSO_NO), it means SRSO_NO
> was manually set by srso_select_mitigation(), and SMT can't possibly be
> enabled.

Have you considered the case where Linux would set SRSO_NO when booting
on future hardware, which is fixed?

There SRSO_NO and SMT will very much be possible.

> Instead of piggybacking on SRSO_NO, which is confusing, why not just add
> a new mitigation type, like:

I had a separate mitigation defintion but then realized I don't need it
because, well, it is not really a mitigation - it is a case where the
machine is not affected.

For example, I have a Zen2 laptop here with SMT disabled in the hardware
which is also not affected.

And also, the rest of the SMT disabled cases in bugs.c do check
sched_smt_active() too, without having a separate mitigation.

That's why.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette