Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp2769735rwi; Tue, 11 Oct 2022 13:08:43 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6bP4vztjCyq/865GIq5aHCksyNJDSTCGie4jqr/H+YNijh6Ji2M/1Unvtgf7Hs4mvPUTK4 X-Received: by 2002:aa7:c78e:0:b0:456:c524:90ec with SMTP id n14-20020aa7c78e000000b00456c52490ecmr24447504eds.192.1665518922929; Tue, 11 Oct 2022 13:08:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665518922; cv=none; d=google.com; s=arc-20160816; b=BgWRv9B2aN58T2OA7FvbQZywGWJJjyRg/LlF+DrpOA53+6bfPIREA2Hr6F7cmy5Sw/ Ce1wqMolR3IfKTFglE5Pc2imHO6FC9Q5Dg89pABvc8P/fOMliCckEaSVbP6JdKGH0UQ8 joEDm52nC6wfOaDEw73j10fEzUoQ3NWpvgKWrCQdPJe2GnWqD+UyjsI5XNKCsV4kqoTC eQN+p530fN2UDwVkSUL0zxYyyd1RzMxzfNE55EtehBFXT3hIarwXp+tAgUiquzTSv23y pecm0E7NK+b+mxob5Mbi9+aqVHlWGkbKQc1LrPNWRhAqatvQ/DvWrCQLbP95rYgsOZkF +8VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=/8LEP6iTQrSruVuUlMCIfaNsSoU3M6nvioOPFUPzrh0=; b=msue+nf0vOel9qrHImZR2aLPi7BXQBdChBjAmd1UGDIC3gGXUxUVJrhA6Dz/8ckdKC beYZQ8xEZx7fDSJCBDU5LHgiNTLGi86sJARr6nL8rZvga3EBKRFr4A4dkJsBR7SiuMkX M1l01/3u/U5wxeY1kRT5znhxrFN6tiNNIeRezf5XAfpO2B+fbzCERlRpmQ1JrPohrZGT Pp5NOtPsjwt3+mfQRlKIve3nwqoelbVu1tYrdLdV2txXlndvb4v6lXr+KTisW7l/pUYD TlimCg52WLKbNCU+jAAgkCm1c6szUMKQRD6aYKL9fDz7wosgvuy8JIN/9S+XT4QAAnZ5 dGnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=l0by20+e; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z21-20020a1709060f1500b00787aba35b7asi11974144eji.102.2022.10.11.13.08.09; Tue, 11 Oct 2022 13:08:42 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=l0by20+e; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230000AbiJKUCX (ORCPT + 99 others); Tue, 11 Oct 2022 16:02:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230005AbiJKUCF (ORCPT ); Tue, 11 Oct 2022 16:02:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E67609AF9E; Tue, 11 Oct 2022 13:01:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BFF95612C4; Tue, 11 Oct 2022 20:01:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6889C433D7; Tue, 11 Oct 2022 20:01:51 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="l0by20+e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1665518510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/8LEP6iTQrSruVuUlMCIfaNsSoU3M6nvioOPFUPzrh0=; b=l0by20+ebmJonHYlRKOQTn2Rq/LTha1yH59+bV2KEU74nVxvpahVEdVt1xI2f62NLBAgn3 twsEZXzZOJm9ZMzTNMu4Omevnc6Vjr/aqBgSm2Zr1v9v/kRjssiiteoY/bB3tR2Ys4R5Cx Xs4GBoajGWwllSQHEx3cJfpFhjyEW8I= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 50afa035 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 11 Oct 2022 20:01:50 +0000 (UTC) Date: Tue, 11 Oct 2022 14:01:45 -0600 From: "Jason A. Donenfeld" To: Herbert Xu 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS 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: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Oct 11, 2022 at 05:03:31PM +0800, Herbert Xu wrote: > On Mon, Oct 10, 2022 at 09:15:48AM -0600, Jason A. Donenfeld wrote: > > > > Do you mean to say that other drivers that use hardware-backed keys do > > so by setting "cra_name" to something particular? Like instead of "aes" > > it'd be "aes-but-special-for-this-driver"? If so, that would seem to > > break the design of the crypto API. Which driver did you see that does > > this? Or perhaps, more generally, what are the drivers that Herbert is > > talking about when he mentions the "plenty of existing drivers" that > > already do this? > > Grep for paes for the existing drivers that support this. I don't > have anything against this feature per se, but the last thing we > want is a proliferation of different ways of doing the same thing. 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. 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". I haven't looked carefully, but I assume that's more or less what this patchset does. 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? Or maybe the "paes" kludge is better for other reasons? I don't know really. Just my 2ยข, but feel free to disregard, as I really have nothing to do with this change. Jason