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] [day] [month] [year] [list]
Message-ID: <f31a9a3f-ec9a-44e1-85ae-c0e0391ff0fc@linux.ibm.com>
Date: Wed, 14 Jan 2026 13:12:20 +0100
From: Holger Dengler <dengler@...ux.ibm.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
        linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
        sparclinux@...r.kernel.org, x86@...nel.org,
        Harald Freudenberger <freude@...ux.ibm.com>,
        linux-crypto@...r.kernel.org
Subject: Re: [PATCH 15/36] lib/crypto: s390/aes: Migrate optimized code into
 library

On 07/01/2026 21:34, Eric Biggers wrote:
> On Wed, Jan 07, 2026 at 08:41:02AM +0100, Holger Dengler wrote:
>> Hi Eric,
>>
>> first of all: happy New Year! ANd thanks for the series.
>>
>> On 05/01/2026 06:12, Eric Biggers wrote:
>>> Implement aes_preparekey_arch(), aes_encrypt_arch(), and 
>>> aes_decrypt_arch() using the CPACF AES instructions.
>>
>> I'm not sure, it it makes sense to implement this on s390 at all. The CPACF
>> instructions cover full modes of operations and are  to process more
>> than one cipher-block-size (*). For single-block operations, the performance
>> might be worth than using the generic functions. I will look into it and do
>> some performance tests. If there is a possibility to plug-in to the level
>> where the modes of operation are implemented, it would make much more sense
>> for s390.
>>
>> (*) Yes, it's a bit uncommon, but the CPACF instructions on s390 can process
>> multiple block with a single instruction call! They are so called long running
>> instructions.
> 
> I'm happy to drop the CPACF single-block AES code if it's not
> worthwhile.  I included it only because arch/s390/crypto/ already has
> such code.  Since I'm making it so that the crypto_cipher API simply
> wraps the library API, if this code is not brought into the library it
> will effectively be dropped.  You had pushed back the last time I
> proposed dropping one of the s390 optimizations, even a fairly minor one
> (https://lore.kernel.org/linux-crypto/51fc91b6-3a6e-44f7-ae93-aef0bcb48964@linux.ibm.com/).
> 
> But I have no way to test or benchmark the s390 code myself.  If the
> CPACF single-block AES en/decryption code isn't worthwhile, there's no
> reason to keep it, so I'll remove it.

My assumtion, that the aes single-block-operation operation is slower in CPACF
than in software, seems to be wrong. I did some measurements on different
machines and it turns out, that it is up to ~2x faster doing it in CPACF.

So, sorry for the noise. Please leave your s390 implementation as it is.

PS: I have a simple kunit test for aes (KAT and benchmark for each direction
and key-size). I'll send it in a separate reply. Feel free to pick it.

> As for AES modes, later patchsets are going to introduce
> architecture-optimized AES modes into the library, and the traditional
> crypto API for those modes will similarly be reimplemented on top of it.
> This patchset just focuses on the existing library API for key expansion
> and single block en/decryption as a first step.  (As with the
> traditional API, single block en/decryption is needed as a fallback to
> handle any modes that don't have a standalone implementation.)

Ok. So we'll wait for upcoming patchsets.

-- 
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@...ux.ibm.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ