Received: by 10.192.165.156 with SMTP id m28csp211075imm; Wed, 18 Apr 2018 20:36:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+VyUabmFGuGp9iRHSX/x3G+2REfwIgmdWkYNCPT+CCgenciyKWVJg+U5MTZ6JQf84P71Wt X-Received: by 10.101.81.131 with SMTP id h3mr3758337pgq.110.1524108994853; Wed, 18 Apr 2018 20:36:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524108994; cv=none; d=google.com; s=arc-20160816; b=Tv3BskC/HlMVjH5Erc5kNKK5wiuF6ms9ao1xVuXbeE2RpXFfV+YrcImowkQ/lm+cqJ G1HroIDkaDOxbaxq2pdPAjM/uDno2SgntOPM80hEu99rqOLNzuDQbrmmZ+X42pxGmKBj MIHQhcDSev5GvFXMxOsx9A8TBTRzJi48V+hmypfdmcObX8EkUjbvGPHP1xvWaL3sULqN g/Sz+JTqTXCiYHlOl1YglMlfhFla0CJSt/2UiTfLpaHxr2yD59m/ASo/vf1SkpgCE4KB kV48FPkV4OTN6Zyo/gcJkyei48UGXLaz6S8UpXoz3aVgTrW16pJ586KVsYDZwt3xMDzE QI7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=PHlZmxl25XLalSa/dyzNDafRIJL/YUobjwbJjlzG1cE=; b=ys881i4Z4bLVjn/LZFU6Oc1lMHOraGdfPpF42V0QsjTYG58Jeypm6EG5HKsD2IKqpi xzcIvpr7ujvSpFE4nKcBMc+D0yaAYdMcQRAKPGUNKpH8nFP6g0NRrjFngYIsEqCB3Joz jeUYkMLO6Y4aCD/87AFq0rHjHBpCzvjkX4A4KherztySdnW8NtTlcVajcMi5XaOlr8Z5 hSSrXAW0dOcKda+wj6x1pFoIVm9xPiVCM29B4wRdzqnKwi+/Uw6gdo0oQywYC5rrvs/B 31LxBNC/SbVq9vvbpLd5Y0NT2baBqqWCO5Pj7Unmx6VFq9xD3btLWGFnrrrvgr/7c0mr 2t6A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a17-v6si2715645plm.151.2018.04.18.20.36.20; Wed, 18 Apr 2018 20:36:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753060AbeDSDfR (ORCPT + 99 others); Wed, 18 Apr 2018 23:35:17 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:45006 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752255AbeDSDfQ (ORCPT ); Wed, 18 Apr 2018 23:35:16 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1f90Lo-00051Q-Vl; Thu, 19 Apr 2018 11:35:13 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1f90Ll-0008WP-A4; Thu, 19 Apr 2018 11:35:09 +0800 Date: Thu, 19 Apr 2018 11:35:09 +0800 From: Herbert Xu To: Gilad Ben-Yossef Cc: "David S. Miller" , Ofir Drang , Linux Crypto Mailing List , Linux kernel mailing list Subject: Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys Message-ID: <20180419033509.dbzetnt4bv7lj7cb@gondor.apana.org.au> References: <1522049540-10042-1-git-send-email-gilad@benyossef.com> <1522049540-10042-3-git-send-email-gilad@benyossef.com> <20180330172616.GB28120@gondor.apana.org.au> <20180403101905.GA4245@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 09, 2018 at 11:42:31AM +0300, Gilad Ben-Yossef wrote: > > Please look again. The stub version of cc_is_hw_key() doing that is being > replaced in this patch. The point is that the existing mechanism was unused before and this is new code. So you can't really point to the stubbed-out function as a precedent. > The s390 key and the cryptocell keys are not the same: > > Their is, I believe, is an AES key encrypted by some internal key/algorithm. > > The cryptocell "key" is a token, which is internally comprised of one > or two indexes, referencing slots in the internal memory in the > hardware, and a key size, that describe the size of the key. > > I thought it would be confusing to use "paes" to describe both, since > they are not interchangeable. > You would not be able to feed an paes key that works with the s390 > version to cryptocell and vice verse and get it work. Thanks for the info. > Having said, if you prefer to have "paes" simply designate > "implementation specific token for an AES key" I'm perfectly fine with > that. Well by definition none of these hardware keys will be compatible with each other so I don't really see the point of using individual algorithm names such as paes or haes. This would make sense only if they were somehow compatible with each other. So instead of using algorithm names, you really want refer to the specific driver name, which means that they can all use the same algorithm name. > > As to your patch specifically, there is one issue where you're > > directly dereferencing the key as a struct. This is a no-no because > > the key may have come from user-space. You must treat it as a > > binary blob. The s390 code seems to do this correctly. > > As noted above, the haes "key" is really a token encoding 3 different > pieces of information: My point is that you should not just cast it but instead do a copy to properly aligned kernel memory. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt