Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Elliott, Robert (Servers)" <elliott@hpe.com>
To:     Taehee Yoo <ap420073@gmail.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "hpa@zytor.com" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>,
        "jussi.kivilinna@iki.fi" <jussi.kivilinna@iki.fi>
Subject: RE: [PATCH v2 3/3] crypto: aria: implement aria-avx512
Thread-Topic: [PATCH v2 3/3] crypto: aria: implement aria-avx512
Thread-Index: AQHY8O+fXPj6RpDrIEWfmNHho+KTdK4wfI9A
Date:   Sat, 5 Nov 2022 16:20:16 +0000
Message-ID: <MW5PR84MB1842E11FD1CF7B44703A42B0AB3A9@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
References: <20221105082021.17997-1-ap420073@gmail.com>
 <20221105082021.17997-4-ap420073@gmail.com>
In-Reply-To: <20221105082021.17997-4-ap420073@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?MJYc618y4jD+pacyog2UYygRrFvNvwpxEJTlIPMOfmq8DrKD2e7o560uN/04?=
 =?us-ascii?Q?ECjT6pze63cxszWy49u+GOnfeHaDStULq4dJfKyUOQPKnqMe9gvCLvA0sTJm?=
 =?us-ascii?Q?8kOiCRxmU6FHXUB+Nk3226kzvOuLeACNpBWVykz9tIgLjGUvyLusjNb15f3p?=
 =?us-ascii?Q?3yL9AZ90CJ5DfJMJvG10Dfyfd/Li62+LVATvURWIdsf1tHSUD6vg4YCq6iLF?=
 =?us-ascii?Q?KUWqPiJJgo5dRQEcOFgZzgL92SwlnPdZDHutl2TCsw4etiqL250sDtdq8KjL?=
 =?us-ascii?Q?qRiDILUB+ae29AgV+LsPPeIIO9txNyCSzgJd7z+wYcw/HkulU4im2sM9Q0Kh?=
 =?us-ascii?Q?wcZWzWwEdrEZW6jfbAxkEkdxDYmyMjfb6SdNHUyUoGfrffOQYnL0wihIV8Vo?=
 =?us-ascii?Q?Z9By1dlB5oc1kd8EjP95CHvPTZHv+2cWmio5DW1ACvNZ8+K+gqVJRMdczGgX?=
 =?us-ascii?Q?OLTVyjh07q+l5mttuzQUw7P39j33TcUx+NKdU6YNXKy7QLdId1iSXrfelmrU?=
 =?us-ascii?Q?6O4tJACbwINxRSxL3v4N3YOv9IywNkcBqZQbbiTbmySX6rK1ktRMgToqibu/?=
 =?us-ascii?Q?W9GZwyUL81gE2gmCFiIZpK5ykTKTfapqx+xIzapQrGaOX+AEybmpm9B8m+At?=
 =?us-ascii?Q?3RhKhdSz2LDvru6htp1zeo6YPDAwOqhWEN/xjKBCQlpKpLRQXMyCMti5dir+?=
 =?us-ascii?Q?lZWFo88PKpngI75N8ovy7gf4w6pyVHr59eFK2R1DNdS296qlZNcSqIhMepZl?=
 =?us-ascii?Q?ndIqPywmOHoU1XK69V7SIn3b/Lw49vKBYvNQERG61GvQvNhSdvmJiT/FtBcE?=
 =?us-ascii?Q?/c+j71IneJ+hJf+IiYr0gNCyWXwqK2QAEk1CJvPEfKMTwnFMtCNFSQIU8NPY?=
 =?us-ascii?Q?qud5xkwTvDu+Bbfqyb8zPKoDJojeNePd9BZKIABxroVM23Q8JAAudGsPVJPx?=
 =?us-ascii?Q?RsWhUxOzcOg1hN0i8WBFSud82zT45RE3Sj4deWodw1xn2pSO1tSTnMCEnLjx?=
 =?us-ascii?Q?ATtAZAA7irdSIdSlV1CizXncEXEU9Mv87+mGQuRl11bHYhpVPRVxgAnTp93+?=
 =?us-ascii?Q?VvW1v1JZ2dJ6Ae8RIVCPU9k0L5rwUhzz10jg1pFjWe/m0dSLEww5bL+I/3Hb?=
 =?us-ascii?Q?TMYUBClSXzJKzPNPqg91fOuBqnNWZCk3S9Mb9+NADJgqsgzcfIqIFsEm4ake?=
 =?us-ascii?Q?pIBUNv3dMkWwA+r2DYtYR7zfF9nwYq44etCE9d7m96Dq9YNalVvBMRtpWaWg?=
 =?us-ascii?Q?W8pI4PR86QYv/wovE6AWlGogbv4guh2Aurg0mmcY3zxp4syywp/rpAWROpdr?=
 =?us-ascii?Q?62yYY6iH0uuJZNVDAzquNVhSsfdxXIAQNBRMLTJSAC2XYv/w76luOg7dVgSE?=
 =?us-ascii?Q?GWQw7cdEKVyw4ft6j8CIszES9Eu6Mt//zFu/bPba3h0pPpCFkjl87N+kIB0m?=
 =?us-ascii?Q?5AW5tFEhEl/8EHQeJmCD+K30BqFqmP9EStIVS/vTsw9OuWSfydnnMAqips36?=
 =?us-ascii?Q?BaqHa+/w+hiP4SzgVGVZtAD+Y1H9L3w4rVyAVRMkescuwqYX7Cf7wdeJgNqt?=
 =?us-ascii?Q?LnO9kpuubRBRV9KVqaM=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: e682ae7e-1cfb-46fe-9f2d-08dabf499fee
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2022 16:20:16.2455
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ShhGyDjlPpljEpIUe0rceFygxpTmn1ZRWAQbUPJlKRRoNYzhWcUG+kHkLK9gPhSp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR84MB1485
X-OriginatorOrg: hpe.com
X-Proofpoint-GUID: GOdAIbrYZK0GsrLP57fkulQpNxRXVGik
X-Proofpoint-ORIG-GUID: GOdAIbrYZK0GsrLP57fkulQpNxRXVGik
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-05_09,2022-11-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0
 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 malwarescore=0
 mlxscore=0 adultscore=0 suspectscore=0 clxscore=1011 phishscore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2211050123
X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> +++ b/arch/x86/crypto/aria-gfni-avx512-asm_64.S
...
> +/* struct aria_ctx: */
> +#define enc_key 0
> +#define dec_key 272
> +#define rounds 544

I've noticed other modules with assembly code also has=20
hardcoded assumptions about the offsets in the context
structure. Sometimes they don't use macros, so they're
less apparent. Example from aesni:

SYM_FUNC_START(aesni_dec)
        FRAME_BEGIN
#ifndef __x86_64__
        pushl KEYP
        pushl KLEN
        movl (FRAME_OFFSET+12)(%esp), KEYP      # ctx
        movl (FRAME_OFFSET+16)(%esp), OUTP      # dst
        movl (FRAME_OFFSET+20)(%esp), INP       # src
#endif
        mov 480(KEYP), KLEN             # key length
        add $240, KEYP
        movups (INP), STATE             # input
        call _aesni_dec1


To ensure the C code and assembly code stay in agreement,
it might be prudent to add a compile-time check in one of
the C functions for each hardcoded offset value, like this
for aesni:

diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-int=
el_glue.c
index 5db4814583ea..e4bcba765c77 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -288,6 +288,10 @@ static int aes_set_key_common(struct crypto_tfm *tfm, =
void *raw_ctx,
        struct crypto_aes_ctx *ctx =3D aes_ctx(raw_ctx);
        int err;

+       BUILD_BUG_ON(offsetof(struct crypto_aes_ctx, key_enc) !=3D 0);
+       BUILD_BUG_ON(offsetof(struct crypto_aes_ctx, key_dec) !=3D 240);
+       BUILD_BUG_ON(offsetof(struct crypto_aes_ctx, key_length) !=3D 480);
+
        if (key_len !=3D AES_KEYSIZE_128 && key_len !=3D AES_KEYSIZE_192 &&
            key_len !=3D AES_KEYSIZE_256)
                return -EINVAL;

The sha functions and sm3 have such a check for the first field
(but only that one) in their context structures:
    static int sha1_update(struct shash_desc *desc, const u8 *data,
    ...
        /*
         * Make sure struct sha1_state begins directly with the SHA1
         * 160-bit internal state, as this is what the asm functions expect=
.
         */
        BUILD_BUG_ON(offsetof(struct sha1_state, state) !=3D 0);