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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F95FC282CE for ; Mon, 8 Apr 2019 08:59:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 313FB20870 for ; Mon, 8 Apr 2019 08:59:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=insidesecure.onmicrosoft.com header.i=@insidesecure.onmicrosoft.com header.b="cmg/wNnc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726510AbfDHI7H (ORCPT ); Mon, 8 Apr 2019 04:59:07 -0400 Received: from mail-eopbgr150107.outbound.protection.outlook.com ([40.107.15.107]:17825 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726396AbfDHI7H (ORCPT ); Mon, 8 Apr 2019 04:59:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insidesecure.onmicrosoft.com; s=selector1-insidesecure-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4WoI/2OMIZGFpiA0iXCMbswvWPJjr9qHwxBd1+5K0E=; b=cmg/wNncn4a2f6QJ712PIlfQiJ99O+PFRT7mKJkfhuD3x/dFwF+fb2es5l+EYRQz2Emkr1UIGEIcdK4Fyu+VhZJ+cNVJL+E60TK5gHJ+abVJOLB2CmYsvo92p5KPrvBczCiwZMgER0gOi/wMtCBZH+PI14rvFOU6MJi2z1wIrak= Received: from AM6PR09MB3523.eurprd09.prod.outlook.com (10.255.99.206) by AM6PR09MB3554.eurprd09.prod.outlook.com (10.255.99.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Mon, 8 Apr 2019 08:59:03 +0000 Received: from AM6PR09MB3523.eurprd09.prod.outlook.com ([fe80::6112:a401:331e:a9b9]) by AM6PR09MB3523.eurprd09.prod.outlook.com ([fe80::6112:a401:331e:a9b9%6]) with mapi id 15.20.1771.011; Mon, 8 Apr 2019 08:59:03 +0000 From: Pascal Van Leeuwen To: Herbert Xu CC: Eric Biggers , Zhang Zhijie , Heiko Stuebner , Ard Biesheuvel , Zain Wang , Arnd Bergmann , "linux-rockchip@lists.infradead.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Olof Johansson , "ezequiel@collabora.com" , linux-arm-kernel , Tao Huang Subject: RE: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Thread-Topic: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Thread-Index: AQHU2t+fclaO8KhrhESirEuEC3Q5mqYsHxyQgAA+MoCABGuWgIAAZ0FggAC6V4CAAAzmIA== Date: Mon, 8 Apr 2019 08:59:02 +0000 Message-ID: References: <20190126210530.GB709@sol.localdomain> <1894799.pWIprST79S@phil> <20190315033140.GB1671@sol.localdomain> <20190404171204.GA121392@gmail.com> <20190407124211.fv7pjsozxhnhw56i@gondor.apana.org.au> <20190408055841.xa5dof4e5xqgaitv@gondor.apana.org.au> In-Reply-To: <20190408055841.xa5dof4e5xqgaitv@gondor.apana.org.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pvanleeuwen@insidesecure.com; x-originating-ip: [188.204.2.113] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2fc44c28-70f7-4753-adc6-08d6bc0072c7 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020);SRVR:AM6PR09MB3554; x-ms-traffictypediagnostic: AM6PR09MB3554: x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(346002)(396003)(39840400004)(136003)(376002)(366004)(189003)(199004)(446003)(478600001)(11346002)(6246003)(25786009)(6116002)(229853002)(71190400001)(81166006)(52536014)(68736007)(2906002)(5660300002)(3846002)(6506007)(81156014)(14444005)(76176011)(486006)(6436002)(8676002)(14454004)(86362001)(71200400001)(256004)(6916009)(102836004)(54906003)(7736002)(55016002)(316002)(8936002)(7416002)(26005)(4326008)(53936002)(476003)(99286004)(7696005)(33656002)(186003)(74316002)(105586002)(97736004)(66066001)(9686003)(93886005)(305945005)(106356001);DIR:OUT;SFP:1102;SCL:1;SRVR:AM6PR09MB3554;H:AM6PR09MB3523.eurprd09.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: insidesecure.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: NBHir5ifqJDttHLQVRIpLlcgjsZdgM3ka1wP+E49vttULIdgZOnYfAeAZI+XqxuCcsxmWr1qTVo/2Z1MnXjmDpNTMigqSL/2fcdyZWeLdFD9cLkjbvXvXbk2u/xmo34OiiOz3Tg7yL3MLTwj9D4LCPAH+anomVLOVS8qUBByKFBlJlDIOtfXiu3w56DZs17T9YLwFJx/caNP6bOscHJLfPBZa+RkNdMtVRUoe5J0R2X3JyRblZjmdykL0A6w3NLtt4+Qur3HywLWC9Qe7P9R7SbUDRbj7jc3O6YKLlZwOZ996c9hq4iS/ayT4G94aM4ihWiyOGLaQrmWh9w5sRCjgxKZUasfhOd6GB/hD87zP3Kjqoy+wuj/Ngezz++wUfQhadwf5rXPinWNUmtQwTcOpBxQk728zj4jv7TsflUzPfI= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: insidesecure.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2fc44c28-70f7-4753-adc6-08d6bc0072c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 08:59:03.0053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3c07df58-7760-4e85-afd5-84803eac70ce X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR09MB3554 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org > > Then where is this specified? Because I read through all the Kernel > > Crypto API documentation multiple times, but I have not been able to > > find ANY reference to any output IV being stored anywhere. > > Yes, I can infer from the source code that this is what the standard > > CBC wrapper does, but that may just as well have been a side-effect of > > that particular implementation. > > Patches to improve the documentation are welcome. > How should someone who did not architect the API himself know the documentation is wrong in this regard? The documentation is the only thing I have available to go by ... > Any drivers not obeying this API rule will be broken when used in conjunc= tion > with algif_skcipher as well as templates such as cts. > Ok, so removing it breaks some existing functionality, that might be a va= lid reason to keep it in ... BUT these may still not be relevant use cases for = a certain hardware accelerator. Which was NOT a problem until the testmgr started actually *failing* and *disabling* implementations on these feature= s. (the iv output is just the tip of the iceberg here, really ...) So now implementors of hw crypto acceleration have 2 options: 1) tell their customers to keep the run-time self-tests disabled, which mak= es them look bad -or- 2) implement some convoluted work-around in the driver that will slow down their actual main use cases to the point where the HW becomes useless It would be nice to have some option in testmgr to just test the core algor= ithm itself and not all the nitty gritty corners of the API that may not be rele= vant i.e. split off the core algorithm cases (e.g. proper straightforward encryp= tion of a single block of data with a certain key) from the API cases. Perhaps a driver could advertise this through some flag: "I'm not fully API compliant, so just test the algorithm and not any API corner cases". Or eve= n "please don't test me, I will test myself". An alternative approach would be capability flags to advertise specific API features, but I can see how you can quickly go overboard with that. But please do keep in mind that: a) These crypto accelerators were NOT designed specifically for the Kernel Crypto API, in fact, the majority of them predate it by quite some margin. They may have very specific target use cases, like IPsec acceleration or disk encryption and not be able to (efficiently) support other API features= . b) Some features are simply NOT suitable for HW acceleration. A HW centric API would not advertise those, but we are where we are now ... c) Working around a) or b) in the driver is sometimes possible, but you don= 't want to do that for exception cases as it slows down the common case. Regards, Pascal From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pascal Van Leeuwen Subject: RE: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Date: Mon, 8 Apr 2019 08:59:02 +0000 Message-ID: References: <20190126210530.GB709@sol.localdomain> <1894799.pWIprST79S@phil> <20190315033140.GB1671@sol.localdomain> <20190404171204.GA121392@gmail.com> <20190407124211.fv7pjsozxhnhw56i@gondor.apana.org.au> <20190408055841.xa5dof4e5xqgaitv@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190408055841.xa5dof4e5xqgaitv-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Herbert Xu Cc: Tao Huang , Zhang Zhijie , Zain Wang , Heiko Stuebner , Arnd Bergmann , Ard Biesheuvel , Eric Biggers , "linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Olof Johansson , "ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org" , linux-arm-kernel List-Id: linux-rockchip.vger.kernel.org > > Then where is this specified? Because I read through all the Kernel > > Crypto API documentation multiple times, but I have not been able to > > find ANY reference to any output IV being stored anywhere. > > Yes, I can infer from the source code that this is what the standard > > CBC wrapper does, but that may just as well have been a side-effect of > > that particular implementation. > > Patches to improve the documentation are welcome. > How should someone who did not architect the API himself know the documentation is wrong in this regard? The documentation is the only thing I have available to go by ... > Any drivers not obeying this API rule will be broken when used in conjunction > with algif_skcipher as well as templates such as cts. > Ok, so removing it breaks some existing functionality, that might be a valid reason to keep it in ... BUT these may still not be relevant use cases for a certain hardware accelerator. Which was NOT a problem until the testmgr started actually *failing* and *disabling* implementations on these features. (the iv output is just the tip of the iceberg here, really ...) So now implementors of hw crypto acceleration have 2 options: 1) tell their customers to keep the run-time self-tests disabled, which makes them look bad -or- 2) implement some convoluted work-around in the driver that will slow down their actual main use cases to the point where the HW becomes useless It would be nice to have some option in testmgr to just test the core algorithm itself and not all the nitty gritty corners of the API that may not be relevant i.e. split off the core algorithm cases (e.g. proper straightforward encryption of a single block of data with a certain key) from the API cases. Perhaps a driver could advertise this through some flag: "I'm not fully API compliant, so just test the algorithm and not any API corner cases". Or even "please don't test me, I will test myself". An alternative approach would be capability flags to advertise specific API features, but I can see how you can quickly go overboard with that. But please do keep in mind that: a) These crypto accelerators were NOT designed specifically for the Kernel Crypto API, in fact, the majority of them predate it by quite some margin. They may have very specific target use cases, like IPsec acceleration or disk encryption and not be able to (efficiently) support other API features. b) Some features are simply NOT suitable for HW acceleration. A HW centric API would not advertise those, but we are where we are now ... c) Working around a) or b) in the driver is sometimes possible, but you don't want to do that for exception cases as it slows down the common case. Regards, Pascal 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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62D93C282CE for ; Mon, 8 Apr 2019 08:59:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2F3E420870 for ; Mon, 8 Apr 2019 08:59:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RfN5ZuRB"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=insidesecure.onmicrosoft.com header.i=@insidesecure.onmicrosoft.com header.b="cmg/wNnc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F3E420870 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=insidesecure.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Lv/tv5X0viiYF5KHu4Q/Vnipk+sD1qbMMwASdb2wj3s=; b=RfN5ZuRBIVPhHm vC0OOx70qo983ouNgtmMQ32ebsGfDwYvi7PWI07N0OBA71nb70SuHiAtS+Hi82tZIrxiiGzMnowK2 FJ8GcCsMiUeMR0QXKjG4+qftsP2UvZi8pMtllI3K4sz1Bz/tPCsaRUNYarH8RDrHkoRXNexee3Vql 0/UBKdLXeJp2xMnFwKnFtdVULzBJZhpc/Es5N8i46QX3T4GL5S7dxq5HgIJKNLeXTj0AZXfM/kqcf lKc6ye50m/bBPZ77AmRzBIWmLUtEvQVCIThwOmrvZHUnlW5QfyZiC9PzT9/DBNcbeLyOGJFDmyyuY mvftPxlAlcURPgqStHNQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDQ7T-0003kA-DA; Mon, 08 Apr 2019 08:59:11 +0000 Received: from mail-eopbgr150135.outbound.protection.outlook.com ([40.107.15.135] helo=EUR01-DB5-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDQ7O-0003i7-Jj; Mon, 08 Apr 2019 08:59:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insidesecure.onmicrosoft.com; s=selector1-insidesecure-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4WoI/2OMIZGFpiA0iXCMbswvWPJjr9qHwxBd1+5K0E=; b=cmg/wNncn4a2f6QJ712PIlfQiJ99O+PFRT7mKJkfhuD3x/dFwF+fb2es5l+EYRQz2Emkr1UIGEIcdK4Fyu+VhZJ+cNVJL+E60TK5gHJ+abVJOLB2CmYsvo92p5KPrvBczCiwZMgER0gOi/wMtCBZH+PI14rvFOU6MJi2z1wIrak= Received: from AM6PR09MB3523.eurprd09.prod.outlook.com (10.255.99.206) by AM6PR09MB3554.eurprd09.prod.outlook.com (10.255.99.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Mon, 8 Apr 2019 08:59:03 +0000 Received: from AM6PR09MB3523.eurprd09.prod.outlook.com ([fe80::6112:a401:331e:a9b9]) by AM6PR09MB3523.eurprd09.prod.outlook.com ([fe80::6112:a401:331e:a9b9%6]) with mapi id 15.20.1771.011; Mon, 8 Apr 2019 08:59:03 +0000 From: Pascal Van Leeuwen To: Herbert Xu Subject: RE: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Thread-Topic: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Thread-Index: AQHU2t+fclaO8KhrhESirEuEC3Q5mqYsHxyQgAA+MoCABGuWgIAAZ0FggAC6V4CAAAzmIA== Date: Mon, 8 Apr 2019 08:59:02 +0000 Message-ID: References: <20190126210530.GB709@sol.localdomain> <1894799.pWIprST79S@phil> <20190315033140.GB1671@sol.localdomain> <20190404171204.GA121392@gmail.com> <20190407124211.fv7pjsozxhnhw56i@gondor.apana.org.au> <20190408055841.xa5dof4e5xqgaitv@gondor.apana.org.au> In-Reply-To: <20190408055841.xa5dof4e5xqgaitv@gondor.apana.org.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pvanleeuwen@insidesecure.com; x-originating-ip: [188.204.2.113] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2fc44c28-70f7-4753-adc6-08d6bc0072c7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR09MB3554; x-ms-traffictypediagnostic: AM6PR09MB3554: x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39840400004)(136003)(376002)(366004)(189003)(199004)(446003)(478600001)(11346002)(6246003)(25786009)(6116002)(229853002)(71190400001)(81166006)(52536014)(68736007)(2906002)(5660300002)(3846002)(6506007)(81156014)(14444005)(76176011)(486006)(6436002)(8676002)(14454004)(86362001)(71200400001)(256004)(6916009)(102836004)(54906003)(7736002)(55016002)(316002)(8936002)(7416002)(26005)(4326008)(53936002)(476003)(99286004)(7696005)(33656002)(186003)(74316002)(105586002)(97736004)(66066001)(9686003)(93886005)(305945005)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR09MB3554; H:AM6PR09MB3523.eurprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: insidesecure.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: NBHir5ifqJDttHLQVRIpLlcgjsZdgM3ka1wP+E49vttULIdgZOnYfAeAZI+XqxuCcsxmWr1qTVo/2Z1MnXjmDpNTMigqSL/2fcdyZWeLdFD9cLkjbvXvXbk2u/xmo34OiiOz3Tg7yL3MLTwj9D4LCPAH+anomVLOVS8qUBByKFBlJlDIOtfXiu3w56DZs17T9YLwFJx/caNP6bOscHJLfPBZa+RkNdMtVRUoe5J0R2X3JyRblZjmdykL0A6w3NLtt4+Qur3HywLWC9Qe7P9R7SbUDRbj7jc3O6YKLlZwOZ996c9hq4iS/ayT4G94aM4ihWiyOGLaQrmWh9w5sRCjgxKZUasfhOd6GB/hD87zP3Kjqoy+wuj/Ngezz++wUfQhadwf5rXPinWNUmtQwTcOpBxQk728zj4jv7TsflUzPfI= MIME-Version: 1.0 X-OriginatorOrg: insidesecure.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2fc44c28-70f7-4753-adc6-08d6bc0072c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 08:59:03.0053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3c07df58-7760-4e85-afd5-84803eac70ce X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR09MB3554 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190408_015906_685117_EF4EF824 X-CRM114-Status: GOOD ( 16.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tao Huang , Zhang Zhijie , Zain Wang , Heiko Stuebner , Arnd Bergmann , Ard Biesheuvel , Eric Biggers , "linux-rockchip@lists.infradead.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Olof Johansson , "ezequiel@collabora.com" , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org > > Then where is this specified? Because I read through all the Kernel > > Crypto API documentation multiple times, but I have not been able to > > find ANY reference to any output IV being stored anywhere. > > Yes, I can infer from the source code that this is what the standard > > CBC wrapper does, but that may just as well have been a side-effect of > > that particular implementation. > > Patches to improve the documentation are welcome. > How should someone who did not architect the API himself know the documentation is wrong in this regard? The documentation is the only thing I have available to go by ... > Any drivers not obeying this API rule will be broken when used in conjunction > with algif_skcipher as well as templates such as cts. > Ok, so removing it breaks some existing functionality, that might be a valid reason to keep it in ... BUT these may still not be relevant use cases for a certain hardware accelerator. Which was NOT a problem until the testmgr started actually *failing* and *disabling* implementations on these features. (the iv output is just the tip of the iceberg here, really ...) So now implementors of hw crypto acceleration have 2 options: 1) tell their customers to keep the run-time self-tests disabled, which makes them look bad -or- 2) implement some convoluted work-around in the driver that will slow down their actual main use cases to the point where the HW becomes useless It would be nice to have some option in testmgr to just test the core algorithm itself and not all the nitty gritty corners of the API that may not be relevant i.e. split off the core algorithm cases (e.g. proper straightforward encryption of a single block of data with a certain key) from the API cases. Perhaps a driver could advertise this through some flag: "I'm not fully API compliant, so just test the algorithm and not any API corner cases". Or even "please don't test me, I will test myself". An alternative approach would be capability flags to advertise specific API features, but I can see how you can quickly go overboard with that. But please do keep in mind that: a) These crypto accelerators were NOT designed specifically for the Kernel Crypto API, in fact, the majority of them predate it by quite some margin. They may have very specific target use cases, like IPsec acceleration or disk encryption and not be able to (efficiently) support other API features. b) Some features are simply NOT suitable for HW acceleration. A HW centric API would not advertise those, but we are where we are now ... c) Working around a) or b) in the driver is sometimes possible, but you don't want to do that for exception cases as it slows down the common case. Regards, Pascal _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel