linux-kernel - Re: [RFC PATCH 0/2] Branch Target Injection (BTI) gadget in minstrel

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: <Y1fDiJtxTe8mtBF8@hirez.programming.kicks-ass.net>
Date:   Tue, 25 Oct 2022 13:07:52 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc:     scott.d.constable@...el.com, daniel.sneddon@...ux.intel.com,
        Jakub Kicinski <kuba@...nel.org>, dave.hansen@...el.com,
        Johannes Berg <johannes@...solutions.net>,
        Paolo Abeni <pabeni@...hat.com>,
        antonio.gomez.iglesias@...ux.intel.com,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, gregkh@...uxfoundation.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Branch Target Injection (BTI) gadget in minstrel

On Mon, Oct 24, 2022 at 03:57:45PM -0700, Pawan Gupta wrote:

> The other goal of this series is to start a discussion on whether such
> hard to exploit, but theoretical possible attacks deems to be mitigated.
> 
> In general Branch Target Injection class of attacks involves an adversary
> controlling an indirect branch target to misspeculate to a disclosure gadget.
> For a successful attack an adversary also needs to control the register
> contents used by the disclosure gadget.

I'm thinking this is going about it wrong. You're going to be randomly
sprinking LFENCEs around forever if you go down this path making stuff
slower and slower.

Not to mention that it's going to bitrot; the function might change but
the LFENCE will stay, protecting nothing but still being slow.

I think the focus should be on finding the source sites, not protecting
the target sites. Where can an attacker control the register content and
have an indirect jump/call.

Also, things like FineIBT will severely limit the viability of all this.

And how is sprinking random LFENCEs around better than running with
spectre_v2=eibrs,retpoline which is the current recommended mitigation
against all this IIRC (or even eibrs,lfence for lesser values of
paranoia).