From:   Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
To:     Eric Biggers <ebiggers@kernel.org>
CC:     Herbert Xu <herbert@gondor.apana.org.au>,
        Zhang Zhijie <zhangzj@rock-chips.com>,
        Heiko Stuebner <heiko@sntech.de>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Zain Wang <wzz@rock-chips.com>, Arnd Bergmann <arnd@arndb.de>,
        "linux-rockchip@lists.infradead.org" 
        <linux-rockchip@lists.infradead.org>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>, Olof Johansson <olof@lixom.net>,
        "ezequiel@collabora.com" <ezequiel@collabora.com>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Tao Huang <huangtao@rock-chips.com>
Subject: RE: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext
Thread-Topic: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext
Thread-Index: AQHU2t+fclaO8KhrhESirEuEC3Q5mqYsHxyQgAA+MoCABGuWgIAAZ0FggAGLsACAAXZKUA==
Date:   Tue, 9 Apr 2019 16:58:10 +0000
Message-ID: <AM6PR09MB35234B24CF735E0FB481D6C8D22D0@AM6PR09MB3523.eurprd09.prod.outlook.com>
References: <20190126210530.GB709@sol.localdomain>
 <CAKv+Gu-RKu9jt+2FnV2529zqyLGR8RSu8r4B8eOs-7Om-pL0aQ@mail.gmail.com>
 <1894799.pWIprST79S@phil>
 <f7a0d04c-339e-d9f8-7188-a27d55ad8b4d@rock-chips.com>
 <20190315033140.GB1671@sol.localdomain>
 <AM5PR0901MB115570ABE89DC1285AE07E60D2500@AM5PR0901MB1155.eurprd09.prod.outlook.com>
 <20190404171204.GA121392@gmail.com>
 <20190407124211.fv7pjsozxhnhw56i@gondor.apana.org.au>
 <AM6PR09MB352377D3A58CE6C12464414ED2530@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190408182757.GD9145@gmail.com>
In-Reply-To: <20190408182757.GD9145@gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: insidesecure.com does not
 designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 572c916f-2f70-425d-b71f-08d6bd0c8bd9
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 16:58:10.1181
 (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: AM6PR09MB2664
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> I really shouldn't have to say this, but just because something hasn't
> been
> reported doesn't mean it's not a real problem.  Someone could easily be
> affected
> by one of these bugs where crypto drivers produce the wrong output, and
> never
> notice it because their use case doesn't involve checking the output
> against
> another implementation.  Or, perhaps they noticed but never reported it
> upstream.  Or perhaps they didn't have the time or skill to debug the
> problem so
> just they disabled the broken driver, or used No Crypto instead.
>
> That's why we have tests -- so bugs can be detected immediately rather
> than
> maybe years out in the field after causing critical security
> vulnerabilities.
>
I understand where you're coming from. My first assumption was that
perhaps this corner of the API was not used at all, in which case the
specification and testmgr could simply be updated to remove it.
I suppose that's not entirely the case. But the few (?) users relying
on this functionality could still be changed to use an alternative
approach such as extracting the output IV from the packet data so any
uses NOT needing this output IV are not bothered with it. That may
actually help the performance of software implementations as well.
Somehow, somewhere, that data must be duplicated, which takes time.

In any, we already came up with the alternative approach of having
some kind of "I_DONT_NEED_IVOUT" flag provided by the user.

Regards,
Pascal