Received: by 10.213.65.68 with SMTP id h4csp2344805imn; Mon, 9 Apr 2018 01:46:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/lKtWxstv0Uyep9D4gkqXiNhCHoG2W6RCmCCyLTKe7O433buvFmNSv+SYU+Op1R187/Hdc X-Received: by 10.99.186.28 with SMTP id k28mr3280044pgf.351.1523263582689; Mon, 09 Apr 2018 01:46:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523263582; cv=none; d=google.com; s=arc-20160816; b=RQh9pgkmqazQorjhdy021/yWRN4gH4J3mGVrmzgZY1G4gYPjQEud846M8YFKqQlZdg hz8q7FZIs/JUPuxnlz6/6g5xaHgzlGrZ5paVfFo69gZirZnCgeDo9Dmne8tO8SfwlwdB sMWcwPOLVdSpNQRjCQLRCYUpNUYGpSi3No65c2bz2XtUyGGytKvvxbazTlpB023Jh/gn p+OpJk4bSw25RypgNyce81BKuLH7a1seOJJa6AaW5dGl/Wes4WfKhWSuhStGoAYCcv8s MyCRN8/Q0inWj+rTb3lWqqEDV+7BpY31geZvv4kd/sA21Gn4/y5U9BglxiZ4XoOTkGLD w3qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=f1gSU5hoYfJL2KaRiBziqLCAhB/ft74wkIiVDHf/1tM=; b=gEdV6voskohC8mpCyMA6i+XerZZC5U6QrF7kQI3G6t2JiUixs41GpuGQ2Y3OlZ0hXX Qye6cBUsVM2LNoGeo8VJBs3we/zgNILk433dPAklRvdLOWx3nEwNlYftmK3WWcYe7RRR Qxo6WoUTh4HhFr1MgX+y5tLV7XS5eNiM/ojFqEytSpC3FLmF9f/ueWUfe+6zQKZ08To5 axTrZbfH0LgwDO8RTMV7NMuaYHq/3wvo2g0Zpx2gqDWJNzCRx8qlNRudvJ4q9Xgo9/+9 uoGJFUvX9dpZRHvJo0U+bBexW3J5Fz8IfMNsJSB11LK90IKhWwt4kETKHLZgbWh+Dexj 02Xw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@benyossef-com.20150623.gappssmtp.com header.s=20150623 header.b=1W7qJmwQ; 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 y7-v6si14071611plh.583.2018.04.09.01.45.45; Mon, 09 Apr 2018 01:46:22 -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; dkim=pass header.i=@benyossef-com.20150623.gappssmtp.com header.s=20150623 header.b=1W7qJmwQ; 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 S1752488AbeDIImf (ORCPT + 99 others); Mon, 9 Apr 2018 04:42:35 -0400 Received: from mail-vk0-f54.google.com ([209.85.213.54]:44576 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458AbeDIImc (ORCPT ); Mon, 9 Apr 2018 04:42:32 -0400 Received: by mail-vk0-f54.google.com with SMTP id r184so4250963vke.11 for ; Mon, 09 Apr 2018 01:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=benyossef-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f1gSU5hoYfJL2KaRiBziqLCAhB/ft74wkIiVDHf/1tM=; b=1W7qJmwQ0oReyWUgq434vqrkuBRq/Yax5J+pXA98QAMOqto/uwhWo9vaMDj6wZJWn4 8xPJUv7zdW0UZXJDBttnvI5wQIYfaFAzews7MugxO4vl+VtGD9CfX8tjGn0bspiB9rco ooP64fCuS/+acqO+Yu8xB1IwQnfh28WAhz/wSuybWgb6idZI9mP58R0mIxIqTTGTArhl QuXFSwpYPgTOfbXsA0FT6JBkzGURO84iq51oDOXv5INKYdAle+Typsv+XD8bQkxfydGu tARqauOPkiVC3tjegjDDRDyCbAhiDpvNOo6sNw+wmzlpiT0j8wpfinZbU1FjNdVZkQTV 8PKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f1gSU5hoYfJL2KaRiBziqLCAhB/ft74wkIiVDHf/1tM=; b=hxZsIB8T4ylECstbu1Em5ti9SakNnz8FzO1To+/F/2a4HKu4wyONDR35npxwSfvE8b CMgfxto8H1C686Oqg/FT808IRjmnwEdmPmKZLU5EZx7SqbTCirx5iZyMtZ/zidn+z8kZ vUuKtbDpQpPhZlw8pdmd/bA7ieZgBMvvDf5pl1FWQi7DK7ui0xyrpYO9vpDlhbRmmeR1 Mb41h/UfarLyxWGlUV8JDdHK9CZq8LvzCTFerXihUfdT6SHYX7a55Tr3zt3wMyztGuM5 ZhV0De+FTvG3uvwsz5epZsytcO1IT1F3lQxsDge+jxsCUdAwfsyn0oOvNxBqmwuk3NxE iGzQ== X-Gm-Message-State: ALQs6tDIlT6A26Btvc3Xke+gm3S4G7NSh1Orjh0Lb9AloCInT4D9FLhY M3I0w9HCOVh6kfKsFCBXak1FWAcroELRaSalVHA9Xw== X-Received: by 10.31.158.8 with SMTP id h8mr23372590vke.24.1523263351963; Mon, 09 Apr 2018 01:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.54.197 with HTTP; Mon, 9 Apr 2018 01:42:31 -0700 (PDT) X-Originating-IP: [62.219.136.235] In-Reply-To: <20180403101905.GA4245@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> From: Gilad Ben-Yossef Date: Mon, 9 Apr 2018 11:42:31 +0300 Message-ID: Subject: Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys To: Herbert Xu Cc: "David S. Miller" , Ofir Drang , Linux Crypto Mailing List , Linux kernel mailing list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 3, 2018 at 1:19 PM, Herbert Xu wrote: > On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote: >> >> However, as it uses the exact same mechanism of the regular xts-aes-ccree >> but takes the key from another source, I've marked it with a test of >> alg_test_null() on the premise that if the xts-aes-ccree works, so must this. > > Well it appears to be stubbed out as cc_is_hw_key always returns > false. Please look again. The stub version of cc_is_hw_key() doing that is being replaced in this patch. >> > Are there other crypto drivers doing this? >> >> I thought the exact same thing until I ran into a presentation about the s390 >> secure keys implementation. I basically imitated their use (or abuse?) >> of the Crypto API >> assuming it is the way to go. >> >> Take a look at arch/s390/crypto/paes_s390.c > > It's always nice to discover code that was never reviewed. :-) > > The general approach seems sane though. > >> Anyway, if this is not the way to go I'd be more than happy to do whatever >> work is needed to create the right interface. >> >> PS. I'd be out of the office and away from email access to the coming week, so >> kindly excuse any delay in response. > > I think it's fine. However, I don't really like the idea of everyone > coming up with their own "paes", i.e., your patch's use of "haes". > It should be OK to just use paes for everyone, no? 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. Having said, if you prefer to have "paes" simply designate "implementation specific token for an AES key" I'm perfectly fine with that. > > 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: 1. The index of the first key slot to use 2. Potentially, the index of a 2nd key slot to use (for XTS) 3. a key size, denoting the actual key size used, not the slot number I than have to parse this information encoded in the token and feed it to the HW (via 3 different registers) Therefore, I do not see how I can avoid parsing the token. I hope I've managed to explain things better now. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru