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: <c27de92c10d05891bc804fe0b955c7428ec534dd.camel@sipsolutions.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ