linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elon Zhang <zhangzj@rock-chips.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: cbc mode broken in rk3288 driver
Date: Fri, 23 Aug 2019 16:20:53 +0800	[thread overview]
Message-ID: <a4b0e750-7881-2b07-8235-4ac98c44153e@rock-chips.com> (raw)
In-Reply-To: <CAKv+Gu-MdY_OizZBNrAt15hr8NSyDG5rDSE65OV6TDmbTLJymw@mail.gmail.com>


On 8/23/2019 15:33, Ard Biesheuvel wrote:
> On Fri, 23 Aug 2019 at 10:10, Elon Zhang <zhangzj@rock-chips.com> wrote:
>> Hi Ard,
>>
>> I will try to fix this bug.
> Good
>
>> Furthermore, I will submit a patch to  set
>> crypto node default disable in rk3288.dtsi.
>>
> Please don't. The ecb mode works fine, and 'fixing' the DT only helps
> if you use the one that ships with the kernel, which is not always the
> case.
>
But crypto node default 'okay' in SoC dtsi is not good since not all 
boards need this

hardware function. It is better that default 'disbale' in SoC dtsi and 
enabled in specific

board dts.

>
>> On 8/20/2019 23:45, Ard Biesheuvel wrote:
>>> Hello all,
>>>
>>> While playing around with the fuzz tests on kernelci.org (which has a
>>> couple of rk3288 based boards for boot testing), I noticed that the
>>> rk3288 cbc mode driver is still broken (both AES and DES fail).
>>>
>>> For instance, one of the runs failed with
>>>
>>>    alg: skcipher: cbc-aes-rk encryption test failed (wrong result) on
>>> test vector \"random: len=6848 klen=32\", cfg=\"random: may_sleep
>>> use_digest src_divs=[93.41%@+1655, 2.19%@+3968, 4.40%@+22]\"
>>>
>>> (but see below for the details of a few runs)
>>>
>>> However, more importantly, it looks like the driver violates the
>>> scatterlist API, by assuming that sg entries are always mapped and
>>> that sg_virt() and/or page_address(sg_page()) can always be called on
>>> arbitrary scatterlist entries
>>>
>>> The failures in question all occur with inputs whose size > PAGE_SIZE,
>>> so it looks like the PAGE_SIZE limit is interacting poorly with the
>>> way the next IV is obtained.
>>>
>>> Broken CBC is a recipe for disaster, and so this should really be
>>> fixed, or the driver disabled.
>>>
>>
>
>



  reply	other threads:[~2019-08-23  8:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 15:45 cbc mode broken in rk3288 driver Ard Biesheuvel
2019-08-23  7:10 ` Elon Zhang
2019-08-23  7:33   ` Ard Biesheuvel
2019-08-23  8:20     ` Elon Zhang [this message]
2019-08-31 15:29       ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4b0e750-7881-2b07-8235-4ac98c44153e@rock-chips.com \
    --to=zhangzj@rock-chips.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).