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]

Date:   Tue, 25 Oct 2022 21:56:21 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     scott.d.constable@...el.com, daniel.sneddon@...ux.intel.com,
        Jakub Kicinski <kuba@...nel.org>, dave.hansen@...el.com,
        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 Tue, 2022-10-25 at 12:38 -0700, Pawan Gupta wrote:
> 
> > 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).
> 
> Its a trade-off between performance and spot fixing (hopefully handful
> of) gadgets. Even the gadget in question here is not demonstrated to be
> exploitable. If this scenario changes, polluting the kernel all over is
> definitely not the right approach.
> 
Btw, now I'm wondering - you were detecting these with the compiler
based something, could there be a compiler pass to insert appropriate
things, perhaps as a gcc plugin or something?

Now honestly I have no idea if it's feasible, but since you're detecting
it that way, and presumably then we'd have to maintain the detection and
run it regularly to make sure that (a) things didn't bitrot and the
gadget is still there, and (b) no new places show up ... perhaps the
better way would be to combine both?

johannes