From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC039C433FE for ; Wed, 12 Oct 2022 09:07:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229546AbiJLJHe (ORCPT ); Wed, 12 Oct 2022 05:07:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiJLJHd (ORCPT ); Wed, 12 Oct 2022 05:07:33 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 911884599A; Wed, 12 Oct 2022 02:07:28 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1oiXgv-00DsnR-3W; Wed, 12 Oct 2022 20:06:18 +1100 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Wed, 12 Oct 2022 17:06:17 +0800 Date: Wed, 12 Oct 2022 17:06:16 +0800 From: Herbert Xu To: "Jason A. Donenfeld" Cc: Pankaj Gupta , "jarkko@kernel.org" , "a.fatoum@pengutronix.de" , "gilad@benyossef.com" , "jejb@linux.ibm.com" , "zohar@linux.ibm.com" , "dhowells@redhat.com" , "sumit.garg@linaro.org" , "david@sigma-star.at" , "michael@walle.cc" , "john.ernberg@actia.se" , "jmorris@namei.org" , "serge@hallyn.com" , "davem@davemloft.net" , "j.luebbe@pengutronix.de" , "ebiggers@kernel.org" , "richard@nod.at" , "keyrings@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , Sahil Malhotra , Kshitiz Varshney , Horia Geanta , Varun Sethi Subject: Re: [EXT] Re: [PATCH v0 3/8] crypto: hbk flags & info added to the tfm Message-ID: References: <20221006130837.17587-1-pankaj.gupta@nxp.com> <20221006130837.17587-4-pankaj.gupta@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Tue, Oct 11, 2022 at 02:01:45PM -0600, Jason A. Donenfeld wrote: > > I've got no stake in this, but isn't the whole idea that if you specify > "aes" you get AES, and if you specify "cbc(aes)" you get AES-CBC, and so > forth? And so leaking implementation details into the algorithm name > feels like it breaks the abstraction a bit. Well, keys stored in hardware are fundamentally incompatible with the algorithm/implementation model. The whole point of having algorithms with multiple implementations (e.g., drivers) is that they all provide exactly the same functionality and could be substituted at will. This completely breaks down with hardware keys because by definition the key is stored in a specific piece of hardware so it will only work with a particular driver. IOW it almost never makes sense to allocate "aes" if you have a hardware key, you almost always want to allocate "aes-mydriver" instead. > Rather, drivers that do AES should be called "aes". For this hardware > key situation, I guess that means keys have a type (in-memory vs > hardware-resident). Then, a crypto operation takes an "algorithm" and a > "key", and the abstraction then picks the best implementation that's > compatible with both the "algorithm" and the "key". No the key is already in a specific hardware bound to some driver. The user already knows where the key is and therefore they know which driver it is. > If you don't want a proliferation of different ways of doing the same > thing, maybe the requirement should be that the author of this series > also converts the existing "paes" kludge to use the new thing he's > proposing? Yes that would definitely be a good idea. We should also talk to the people who added paes in the first place, i.e., s390. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt