Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3031855pxb; Mon, 18 Oct 2021 06:59:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZE5We2yNpmHV7QQbI0g5PPFXjJ7laCeg7ktvvsMYz99vhiqHqWI+FDp2/J7SbT+RenWIw X-Received: by 2002:a17:90a:bd08:: with SMTP id y8mr33117355pjr.123.1634565562048; Mon, 18 Oct 2021 06:59:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634565562; cv=none; d=google.com; s=arc-20160816; b=XmIpa0ufEYhVuBEMevlEr7WAWgWUCCm6WWhmzb1u8S1z0ZgCUxDs530OS+m1R+5QHe bl6gQBPhf3Y+tKoWPWOqw24zittBO41CrQxg44XHoeepSLMtgRFmkkH7Uzkc852y/E+c y5+LeAbYBMI0jb7XDrRdD4F6AI2QMhPyVWcvFgDmZnRs7yEeTSvDkIaz/0Ko6c+lsZI5 uOclfUPpxEqJST0Q7SX5WpW/6KTsOiD3FOUlYEmuU4PwfEomUT5VNxxXPe5fFiHuXQzC RlQ2F5PQAdVDxHrlj405IKRUWOrdgCIqqWX+V+R35DnmpKt8sjPcUiiA23NhPTkl6EX2 tAXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:to:from :subject:message-id:dkim-signature; bh=iyQNCJw3F2btWylGkoSsJbiuAqzwxr7VZp84T8arEwk=; b=CV6Zj0yaTCh8aDKJdFFThK/W7YAq/LnUOQVQI/ocJQQu7yvMwEwpXjloB2uQ8fe4ve wJtvFtbj6wYDAS7HTHOuCh54Eb9aUeCaVIeCSXVdh+OnaL1V0jUQT53eBq87/KjqtzhY DCYgSrZ8CXjGDnmQ1B85fq+80VWYTIAI6TMBNcZQJ99bnhNxPOapqUZTUuRPfY2MHcJb jSXDuMPGz621WLLATfMt09Hyt8rjzgZ7RzH/dsmrzlEKe2f8ot4PLfoHJ/UtpT0oR0ET Ay0UJAX90G7PdmrPWvKnZRNTc1cJQe3RgZUBV+c9bPw0+vAYnkgfVzuD+MELME/H9jyS SaLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Muk1xW0O; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h5si18243113pls.167.2021.10.18.06.58.56; Mon, 18 Oct 2021 06:59:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Muk1xW0O; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234193AbhJROAj (ORCPT + 99 others); Mon, 18 Oct 2021 10:00:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:38242 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234664AbhJRN63 (ORCPT ); Mon, 18 Oct 2021 09:58:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BAF7F61A40; Mon, 18 Oct 2021 13:41:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634564489; bh=iyQNCJw3F2btWylGkoSsJbiuAqzwxr7VZp84T8arEwk=; h=Subject:From:To:Date:In-Reply-To:References:From; b=Muk1xW0O5fPkNs1SObNldVoKqidRwndzDDCkNEC0B0lO2IyZKUCtY8K+mMfUuaYZd cL0KbWMGwXTcZritJ7+AqX/i/Slq2vQ3TFT8qH4dnzifxwAlHnTB0R7fXbt/9Ydo6o R6TW5vdR2I6vipcf13Wm9iIo7VWkS1eEmHIv3H14gJR2CmDKO2uFtJ4JYn5d5YXnpq vEb7U3LYwRzjycvD69cavPuejBiYJODJwHhnF1zOLy2p7gCguIkj9PfbV2Ef/Rzk88 Ktx6XBGnB9cYIhgCbMozT4+fkladPBDQqNT0gUOFJuK42Tvn0S19FEBuRX06p0kTdR 7iRo20kZTREzw== Message-ID: <41aba1e1c5849b58f83108eb9f9f115d0cd5826f.camel@kernel.org> Subject: Re: [PATCH 1/2] crypto: use SM3 instead of SM3_256 From: Jarkko Sakkinen To: jejb@linux.ibm.com, Tianjia Zhang , Mimi Zohar , Jonathan Corbet , Herbert Xu , "David S. Miller" , Peter Huewe , Jason Gunthorpe , David Howells , James Morris , "Serge E. Hallyn" , Jerry Snitselaar , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-security-module@vger.kernel.org Date: Mon, 18 Oct 2021 16:41:26 +0300 In-Reply-To: References: <20211009130828.101396-1-tianjia.zhang@linux.alibaba.com> <20211009130828.101396-2-tianjia.zhang@linux.alibaba.com> <7035153d58e220473fe3cd17c9f574f2d91c740b.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.40.0-1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, 2021-10-18 at 09:32 -0400, James Bottomley wrote: > On Mon, 2021-10-18 at 16:27 +0300, Jarkko Sakkinen wrote: > > On Mon, 2021-10-18 at 09:05 -0400, James Bottomley wrote: > > > On Sat, 2021-10-09 at 21:08 +0800, Tianjia Zhang wrote: > > > [...] > > > > diff --git a/include/uapi/linux/hash_info.h > > > > b/include/uapi/linux/hash_info.h > > > > index 74a8609fcb4d..1355525dd4aa 100644 > > > > --- a/include/uapi/linux/hash_info.h > > > > +++ b/include/uapi/linux/hash_info.h > > > > @@ -32,7 +32,7 @@ enum hash_algo { > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_TGR_128, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_TGR_160, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_TGR_192, > > > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_SM3_256, > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_SM3, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_STREEBOG_256, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO_STREEBOG_512, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HASH_ALGO__LAST > > >=20 > > > This is another one you can't do: all headers in UAPI are exports > > > to userspace and the definitions constitute an ABI.=C2=A0 If you simp= ly > > > do a rename, every userspace program that uses the current > > > definition will immediately break on compile.=C2=A0 You could add > > > HASH_ALGO_SM3, but you can't remove HASH_ALGO_SM3_256 > > >=20 > > > James > >=20 > > So: shouldn't then also the old symbol continue to work also > > semantically? >=20 > Yes, that's the point: you can add a new definition ... in this case an > alias for the old one, but you can't remove a definition that's been > previously exported. Thanks, this of course obvious :-) I forgot temporarily that crypto has uapi interface. Tianjia, this patch set break production systems, so no chance we would ever merge it in this form. Why not just do this: ... HASH_ALGO_SM3_256, HASH_ALOG_SM3 =3D HASH_ALOG_SM_256, ... There is not good reason to mod the implementation because both symbols are kept. /Jarkko