Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <de9d2ae5-e794-6e54-baf6-f83a16d710a3@csgroup.eu>
Date:   Sat, 6 Aug 2022 17:45:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: talitos b0030000.crypto: length exceeds h/w max limit
Content-Language: fr-FR
To:     =?UTF-8?Q?Stephan_M=c3=bcller?= <smueller@chronox.de>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>
References: <4d9e644d-3d2d-518a-3d05-2539c69d88c1@c-s.fr>
 <1955828.3d07pK88Qj@tauon.chronox.de>
 <326109a3-bb5c-eac4-1340-70c179a3ad2a@c-s.fr>
 <10231361.cnp4CI42qt@positron.chronox.de>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
From:   Christophe Leroy <christophe.leroy@csgroup.eu>
In-Reply-To: <10231361.cnp4CI42qt@positron.chronox.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi,

Le 31/07/2019 à 09:11, Stephan Müller a écrit :
>>>>> If I remember correctly, the implementation with vmsplice was slower by
>>>>> a
>>>>> factor of 10 compared to sendmsg on the ISO image on an x86 system.
>>>>
>>>> At the time being I have an issue with this fix, because the talitos
>>>> driver only accepts 32k bytes at a time. With vmsplice, data is handed
>>>> over to the driver by blocks of PAGE_SIZE (16k in my case). With
>>>> sendmsg(), data is handed over to the driver with a single block.
>>>
>>> Ok. But wouldn't your driver need to process the data in the chunk size
>>> your hardware requires?
>>
>> Sure it needs to process the data in the chunk size the HW requires, but
>> do you know if there is a way to tell the core than the driver doesn't
>> accepts chunks of more than 32kbytes, or shall the driver be able to
>> handle data of any size ?
> 
> Coming back to this: Were you able to find a fix?

As far as I know the problem still exists.

We want to upgrade libkcapi on our target, but still facing the issue 
with libkcapi newer than 1.1.3 : When a file is bigger than 32 Kb, 
hashing operation (md5 or sha256) fails and the kernel prints the 
following message:

[ 2369.772999] talitos b0030000.crypto: length exceeds h/w max limit

Is there a way to tell crypto kernel core that a given driver has a 
fixed limit and that data shall be sent in chunks ? Or is it the 
responsibility of the driver to cut off the data in acceptable chunks ? 
I guess the Talitos driver is not the only driver with such a limit, so 
something centralised must exist to handle it ?

Thanks
Christophe