linux-kernel - Re: [PATCH v3 11/15] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions

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: <1F509A28-1A49-4F60-9E96-B2AD9CC6E921@intel.com>
Date:   Mon, 6 Dec 2021 22:59:09 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Ard Biesheuvel <ardb@...nel.org>
CC:     Eric Biggers <ebiggers@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Gairuboyina, Charishma1" <charishma1.gairuboyina@...el.com>,
        "Dwarakanath, Kumar N" <kumar.n.dwarakanath@...el.com>,
        "Krishnakumar, Lalithambika" <lalithambika.krishnakumar@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: Re: [PATCH v3 11/15] crypto: x86/aes-kl - Support AES algorithm using
 Key Locker instructions

On Dec 6, 2021, at 14:14, Ard Biesheuvel <ardb@...nel.org> wrote:
> On Tue, 30 Nov 2021 at 07:57, Bae, Chang Seok <chang.seok.bae@...el.com> wrote:
>> 
>> 
>> No, these two instruction sets are separate. So I think no room to share the
>> ASM code.
> 
> On arm64, we have
> 
> aes-ce.S, which uses AES instructions to implement the AES core transforms
> 
> aes-neon.S, which uses plain NEON instructions to implement the AES
> core transforms
> 
> aes-modes.S, which can be combined with either of the above, and
> implements the various chaining modes (ECB, CBC, CTR, XTS, and a
> helper for CMAC, CBCMAC and XMAC)
> 
> If you have two different primitives for performing AES transforms
> (the original round by round one, and the KL one that does 10 or 14
> rounds at a time), you should still be able to reuse most of the code
> that implements the non-trivial handling of the chaining modes.

Yes, no question about this for maintainability.

However, besides the fact that a KL instruction takes multiple rounds, some
AES-KL instructions have register constraints. E.g. AESENCWIDE256KL always
uses XMM0-7 for input blocks.

Today, AES-NI code maintains 32-bit compatibility, e.g. clobbering XMM2-3 for
key and input vector, so sharing the code makes the AES-KL code inefficient
and even ugly I think due to the register constraint. E.g. the AES-KL code
does use XMM9-10 for key and an input vector, but it has to move them around
just for code sharing.

Thanks,
Chang