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=0.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 D430BC10F14 for ; Mon, 8 Apr 2019 18:10:25 +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 A999E2084C for ; Mon, 8 Apr 2019 18:10:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NjgqwyKg"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="WaP4NlJZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A999E2084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zQduDNKgomx3L9Ngp5btMPa6DQEC7dWZ8esYp+yOiu0=; b=NjgqwyKgCPqjwW /b4JFmyWA+oJi4HxdDgHWrkJy8YHqtE3NY+GTWUcEsZ8PsXybq9DDbRhnBP/qMOcopUUuKXmXjL1Y dPRnsTkjuuGF8exrboPVaTNZmjBujbFFD5Jd3NFvV3+ZTFwjj9aST0tL1HCnSCv195Mwl8olJyEBr un8wlUriMFpLJU8q/SaIaPkRSidROzZcn3jB1b6nMj4a5GvXnBHpn69Hs3frxRCJ2stdCoTifkVWG x9S9dyVPY2gXs8J4rLW5DppP7InOjWTYdEZVUR7qApA3AXzOl9qo/3d13Z9SoybcEKIV8ZpKeylyF 9/cpTR/W973+ujJk4Asw==; 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 1hDYiq-0001kZ-Sc; Mon, 08 Apr 2019 18:10:20 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDYiP-00005j-Ja; Mon, 08 Apr 2019 18:09:55 +0000 Received: from gmail.com (unknown [104.132.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7CD012084C; Mon, 8 Apr 2019 18:09:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554746992; bh=qohZBkxzTQ/PNO9RvWjmihCXJAoGeXyjjMpN//eXMt0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WaP4NlJZwdxJCmDBIT2le7TCRK4HXYmnBstsJhamOAJolv4adexnPKf5ZVuj71n15 K6BwYBkHVaPRVx8hxDAVuZsyFXUMBFynU0Oh4QIw7nhezk7ooOmPYcw66IFQGWhYl4 s/zLv+oAEbmmV+9X9lIBAtgFTGdSLifK98w27O+I= Date: Mon, 8 Apr 2019 11:09:51 -0700 From: Eric Biggers To: Pascal Van Leeuwen Subject: Re: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Message-ID: <20190408180948.GC9145@gmail.com> References: <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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190408_110953_676895_3D6CBB3F X-CRM114-Status: GOOD ( 29.80 ) 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 , Zain Wang , Herbert Xu , Arnd Bergmann , Ard Biesheuvel , Zhang Zhijie , "linux-rockchip@lists.infradead.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Olof Johansson , "ezequiel@collabora.com" , linux-arm-kernel , Heiko Stuebner 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 On Mon, Apr 08, 2019 at 08:59:02AM +0000, Pascal Van Leeuwen wrote: > > > 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. > One person's "corner case" is another person's "use case". Once you register your driver with the crypto API, you can't control how it's used. If you provide "cbc(aes)", for example, anyone in the kernel may get your driver when they ask the crypto API to do "cbc(aes)" encryption or decryption. Correctness comes first, and there's no such thing as "testing the algorithm, not the API", since the API is means by which the algorithm is accessed. So you *must* implement the API correctly. If you don't, it's very much Working As Intended for the self-tests to disable your driver. If you aren't happy with the API, then please work with the community to improve the API instead. E.g. perhaps we should annotate with a new request flag all users who may actually need the IV chaining behavior. Then on all other requests, implementations wouldn't be required to provide the next IV. It would add complexity, but perhaps it would be worthwhile. Remember that in the case of unsupported lengths, keys, or data layouts, you also have the option of using a fallback algorithm to handle those cases. Grep for CRYPTO_ALG_NEED_FALLBACK to see examples in other drivers. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel