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: <7cdbce42-2d40-95bc-d719-62a1580d6ebf@intel.com>
Date:   Fri, 15 Jan 2021 21:13:33 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     "Dey, Megha" <megha.dey@...el.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ravi.v.shankar@...el.com, tim.c.chen@...el.com,
        andi.kleen@...el.com, wajdi.k.feghali@...el.com,
        greg.b.tucker@...el.com, robert.a.kasten@...el.com,
        rajendrakumar.chinnaiyan@...el.com, tomasz.kantecki@...el.com,
        ryan.d.saffores@...el.com, ilya.albrekht@...el.com,
        kyung.min.park@...el.com, Tony Luck <tony.luck@...el.com>,
        ira.weiny@...el.com
Subject: Re: [RFC V1 3/7] crypto: ghash - Optimized GHASH computations

On 1/15/21 6:04 PM, Eric Biggers wrote:
> On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote:
>> On 1/15/21 4:14 PM, Dey, Megha wrote:
>>> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
>> That's true, bit it's also possible that a hypervisor could enumerate
>> support for PCLMULQDQ and not AES-NI.  In general, we've tried to
>> implement x86 CPU features independently, even if they never show up in
>> a real CPU independently.
> We only add optimized implementations of crypto algorithms if they are actually
> useful, though.  If they would never be used in practice, that's not useful.

Yes, totally agree.  If it's not of practical use, it doesn't get merged.

I just wanted to share what we do for other related but independent CPU
features.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ