linux-kernel - Re: [PATCH 15/23] x86/srso: Remove 'pred

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]

Message-ID: <20230826154518.rwu5wyerqhefmhon@treble>
Date:   Sat, 26 Aug 2023 08:45:18 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Nikolay Borisov <nik.borisov@...e.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Babu Moger <babu.moger@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>, David.Kaplan@....com,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        gregkh@...uxfoundation.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 15/23] x86/srso: Remove 'pred_cmd' label

On Fri, Aug 25, 2023 at 10:51:04PM +0300, Nikolay Borisov wrote:
> 
> 
> On 25.08.23 г. 10:01 ч., Josh Poimboeuf wrote:
> > SBPB is only enabled in two distinct cases:
> > 
> > 1) when SRSO has been disabled with srso=off
> > 
> > 2) when SRSO has been fixed (in future HW)
> > 
> > Simplify the control flow by getting rid of the 'pred_cmd' label and
> > moving the SBPB enablement check to the two corresponding code sites.
> > This makes it more clear when exactly SBPB gets enabled.
> > 
> > Signed-off-by: Josh Poimboeuf <jpoimboe@...nel.org>
> 
> 
> I think it never was explained why SBPB should be used when SRSO is off/hw
> is not affected? There's nothing in AMD's whitepape and there's nothing in
> the original patch introducing SRSO_NO. This patch deals with the "when",
> but what about the "Why" ? Can you put this in the changelog (if I'm the
> only one missing this detail)?

This patch was merged, but the "why" is that on Zen3/4, the new
microcode adds branch type flushing to IBPB, making IBPB slower.  SBPB
is the "old" IBPB, without branch type flushing.  So if you don't need
the branch type flushing (i.e., to mitigate SRSO) then you can just use
the old IBPB (aka SBPB).

-- 
Josh