From:   Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
To:     Eric Biggers <ebiggers@kernel.org>,
        Zhang Zhijie <zhangzj@rock-chips.com>
CC:     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+fclaO8KhrhESirEuEC3Q5mqYsHxyQ
Date:   Thu, 4 Apr 2019 13:41:50 +0000
Message-ID: <AM5PR0901MB115570ABE89DC1285AE07E60D2500@AM5PR0901MB1155.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>
In-Reply-To: <20190315033140.GB1671@sol.localdomain>
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: 6a0457de-10a9-4768-12aa-08d6b9034a86
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 13:41:50.3682
 (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: AM5PR0901MB1156
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> The issue is that the self-tests now verify that CBC implementations upda=
te the
> IV buffer to contain the next IV, aka the last ciphertext block.  But the=
 Rockchip
> crypto driver doesn't do that, so it needs to be fixed.
>
> This has always been a requirement for CBC implementations so that users =
can
> chain CBC requests.  Unfortunately it was just never tested for...
>
This did not immediately trigger me when it came flying past a couple of we=
eks
ago, but I ran into the same issue today with the inside_secure driver I'm =
playing
with: it does NOT return correct IV outputs for CBC modes.

However ... I'd like to question that very requirement ... if I may :-)

My reasoning is that this IV output *is* available as the last block of eit=
her the
output (for encrypt) or input (for decrypt) datastream. So requiring it to =
be
updated in the IV buffer as well seems redundant to me. It burdens the driv=
er
with an extra data copy operation, while in the majority of practicle use c=
ases
you would not even *need* this output IV. (chaining IV's would not work on
a hardware accelerator anyway, because you would need to serialize the
datastream, meaning you run at the speed of the round-trip latency instead
of the throughput, which is typically one to two orders of a magnitude slow=
er)

And in the odd case you do need it, you can just grab it from the data buff=
er
yourself.

Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines