linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tero Kristo <t-kristo@ti.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-omap@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 00/10] crypto: omap fixes towards 5.5
Date: Fri, 25 Oct 2019 14:55:23 +0300	[thread overview]
Message-ID: <8f97d690-a88a-55cb-eb67-206e01873d94@ti.com> (raw)
In-Reply-To: <CAKv+Gu_HNOTSvWRTzLMeECaM8qCi5w806ht_e68e5vgcU9aQvQ@mail.gmail.com>

On 25/10/2019 14:33, Ard Biesheuvel wrote:
> On Thu, 17 Oct 2019 at 14:26, Tero Kristo <t-kristo@ti.com> wrote:
>>
>> Hi,
>>
>> This series fixes a number of bugs with omap crypto implementation.
>> These have become evident with the changes to the cryptomanager, where
>> it adds some new test cases and modifies some existing, namely the split
>> update tests. Also, while fixing the cryptomanager induced bugs, some
>> other surfaced with tcrypt/IPSec tests, so fixed them aswell.
>>
>> Patch #9 is against crypto core modifying the crypto_wait_req
>> common API to have a timeout for it also, currently it waits forever
>> and it is kind of difficult to see what test fails with crypto manager.
>> This is not really needed for anything, but it is kind of nice to have
>> (makes debugging easier.)
>>
>> This series has been tested on top of 5.4-rc2, with following setups,
>> on AM57xx-beagle-x15 board:
>>
>> - crypto manager self tests
>> - tcrypt performance test
>> - ipsec test with strongswan
>>
>> This series depends on the skcipher API switch patch from Ard Biesheuvel
>> [1].
>>
> 
> Hi Tero,
> 
> On my BeagleBone White, I am hitting the following issues after
> applying these patches:
> 
> [    7.493903] alg: skcipher: ecb-aes-omap encryption unexpectedly
> succeeded on test vector "random: len=531 klen=32";
> expected_error=-22, cfg="random: inplace may_sleep use_finup
> src_divs=[44.72%@+4028, <flush>14.70%@alignmask+3, 19.45%@+4070,
> 21.13%@+2728]"
> [    7.651103] alg: skcipher: cbc-aes-omap encryption unexpectedly
> succeeded on test vector "random: len=1118 klen=32";
> expected_error=-22, cfg="random: may_sleep use_final
> src_divs=[<reimport>41.87%@+31, <flush>58.13%@+2510]"
> 
> These are simply a result of the ECB and CBC implementations not
> returning -EINVAL when the input is not a multiple of the block size.
> 
> [    7.845527] alg: skcipher: blocksize for ctr-aes-omap (16) doesn't
> match generic impl (1)
> 
> This means cra_blocksize is not set to 1 as it should. If your driver
> uses the skcipher walk API, it should set the walksize to
> AES_BLOCK_SIZE to ensure that the input is handled correctly. If you
> don't, then you can disregard that part.
> 
> [    8.306491] alg: aead: gcm-aes-omap setauthsize unexpectedly
> succeeded on test vector "random: alen=3 plen=31 authsize=6 klen=9";
> expected_error=-22
> 
> Another missing sanity check. GCM only permits certain authsizes.
> 
> [    9.074703] omap_crypto_copy_sgs: Couldn't allocate pages for
> unaligned cases.
> 
> This is not a bug, but I'm not sure if the below is related or not.
> 
> I'll preserve the binaries, in case you need me to objdump anything.

What are these tests you are executing? For me, the testmgr self test 
suite is passing just fine. Any extra tests you have enabled somehow?

I am also running full test on different board though (am57xx), I 
haven't been explicitly running anything on am335x.

-Tero


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-10-25 11:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 12:25 [PATCH 00/10] crypto: omap fixes towards 5.5 Tero Kristo
2019-10-17 12:25 ` [PATCH 01/10] crypto: omap-sham: split up data to multiple sg elements with huge data Tero Kristo
2019-10-17 12:25 ` [PATCH 02/10] crypto: omap-sham: remove the sysfs group during driver removal Tero Kristo
2019-10-17 12:25 ` [PATCH 03/10] crypto: omap-aes: " Tero Kristo
2019-10-17 12:25 ` [PATCH 04/10] crypto: omap-des: add IV output handling Tero Kristo
2019-10-17 12:25 ` [PATCH 05/10] crypto: omap-aes: " Tero Kristo
2019-10-17 12:25 ` [PATCH 06/10] crypto: omap-sham: fix buffer handling for split test cases Tero Kristo
2019-10-17 12:25 ` [PATCH 07/10] crypto: omap-aes-gcm: fix corner case with only auth data Tero Kristo
2019-10-26 15:04   ` Ard Biesheuvel
2019-10-17 12:25 ` [PATCH 08/10] crypto: omap-sham: fix split update cases with cryptomgr tests Tero Kristo
2019-10-17 12:25 ` [PATCH 09/10] crypto: add timeout to crypto_wait_req Tero Kristo
2019-11-05 17:42   ` Eric Biggers
2019-11-06  6:39   ` Gilad Ben-Yossef
2019-11-06  7:25     ` Tero Kristo
2019-11-06  7:33       ` Gilad Ben-Yossef
2019-11-08  2:27         ` Eric Biggers
2019-11-08  7:40           ` Tero Kristo
2019-11-08  9:16             ` Herbert Xu
2019-11-08  9:22               ` Tero Kristo
2019-11-09  2:27                 ` Eric Biggers
2019-11-09  5:01                   ` Herbert Xu
2019-10-17 12:25 ` [PATCH 10/10] crypto: omap-aes: fixup aligned data cleanup Tero Kristo
2019-10-25 11:33 ` [PATCH 00/10] crypto: omap fixes towards 5.5 Ard Biesheuvel
2019-10-25 11:55   ` Tero Kristo [this message]
2019-10-25 11:56     ` Tero Kristo
2019-10-25 12:05       ` Ard Biesheuvel
2019-10-25 12:18         ` Tero Kristo
2019-10-26 15:06           ` 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=8f97d690-a88a-55cb-eb67-206e01873d94@ti.com \
    --to=t-kristo@ti.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-omap@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).