From:   Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        Eric Biggers <ebiggers@kernel.org>
CC:     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+MoCABGuWgIAAZ0Fg
Date:   Sun, 7 Apr 2019 19:12:43 +0000
Message-ID: <AM6PR09MB352377D3A58CE6C12464414ED2530@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>
In-Reply-To: <20190407124211.fv7pjsozxhnhw56i@gondor.apana.org.au>
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: 83c46822-acd6-4ab5-a5ef-08d6bb8d0310
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2019 19:12:43.4488
 (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: AM6PR09MB3431
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> > Herbert, can you explain what users actually rely on the next IV being
> returned?
> > I don't know all the historical context behind this.
>
> Chaining by reusing the output IV has always been part of the API.
>
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.

Fact is, there are at least 2 hardware device drivers NOT doing this - and
I want to bet a nice sum of money there will be more - and that this has
not been noticed prior to adding these tests to testmgr, otherwise this
would have been fixed by now. Which seems to confirm that there is no
real use case for this functionality.

So why would we fail and disable crypto drivers that have been working
perfectly fine so far on their true use cases just because of some purely
theoretical "part of the API" that may just as well be personal opinion?

Or add some expensive work-around to the driver, for that matter.
Expensive, because the driver will have to compute the last crypto block
offset, walk the scatter chain, copy the last block data while taking into
account the corner case where this data is crossing scatter blocks.
That's a lot of overhead for something that has no real use case.

Regards,
Pascal