linux-kernel - Re: [PATCH 2/6] s390: implement nospec

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: <e269adc3-35ba-3ac9-1302-9211374f2d34@redhat.com>
Date:   Wed, 17 Jan 2018 09:52:09 -0500
From:   Jon Masters <jcm@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        kvm@...r.kernel.org, Heiko Carstens <heiko.carstens@...ibm.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcus Meissner <meissner@...e.de>
Subject: Re: [PATCH 2/6] s390: implement nospec_[load|ptr]

On 01/17/2018 07:41 AM, Jiri Kosina wrote:
> On Wed, 17 Jan 2018, Martin Schwidefsky wrote:
> 
>> Implement nospec_load() and nospec_ptr() for s390 with the new
>> gmb() barrier between the boundary condition and the load that
>> may not be done speculatively.

Thanks for the patches, Martin et al. I tested various earlier versions
and will run these latest ones through some tests and add a tested by.

> FWIW the naming seems to be changing constantly. The latest patchset from 
> Dan Williams [1] uses ifence_...().
> 
> [1] lkml.kernel.org/r/151586744180.5820.13215059696964205856.stgit@...llia2-desk3.amr.corp.intel.com

This is getting a little silly. Not to bikeshed this to death, but
obviously gmb (what was that ever supposed to stand for, global?) was
the wrong name. We favored seb (speculative execution barrier), etc.
Still, "ifence"? What is that supposed to mean? That sounds very
architecture specific vs. what we're actually trying to ensure, which is
that we don't speculatively load a pointer.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop