[dm-crypt] out of order encryption

Milan Broz gmazyland at gmail.com
Thu Aug 6 14:40:00 CEST 2015


On 08/06/2015 02:10 PM, Vasile Catalin-B50542 wrote:
> I am using a Freescale P3041DS platform with CAAM (drivers/crypto/CAAM/*) hardware accelerator.
> The platforms is a PowerPC processor.

Well, I think there is some problem with the crypto driver in kernel.

And because I see that this driver is currently in active development, I would suggest
to contact the developer and ask for an advice, see
http://thread.gmane.org/gmane.linux.kernel.cryptoapi/16176

Unfortunately we do not have this hw available so I cannot provide more help here.

You can try to compile cryptsetup with --disable-kernel_crypto option - maybe it is a workaround.
(But there can be a data corruption later...)

Anyway, if it works, the I would guess there is a bug in userspace interface code.

Maybe it can help how we debugged a similar issue here
http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7966/focus=13358

Milan

> 
> On 06.08.2015 14:48, Milan Broz wrote:
>> On 08/06/2015 01:32 PM, Vasile Catalin-B50542 wrote:
>>> I am sending crypto requests to a hardware component which has
>>> an option to keeping them in order or not. I was trying to use the out of
>>> order option because this would let requests run in parallel.
>>> If I tried running them with the out of order option bun then I get:
>>> No key available with this passphrase.
>>> When trying to execute the following commands:
>>> cryptsetup -c aes-xts-plain -y -v luksFormat /dev/sda1
>>> cryptsetup open /dev/sda1 test_xts1
>>
>> Sigh. Please when you asking about some explicit problem, please
>> always mention it from the beginning...
>>
>> So this is probably unrelated to dmcrypt. Userspace cryptsetup could use
>> kernel crypto API wrapper directly (add --debug and you will see,
>> there should be log message that it uses kernel crypto userspace interface).
>>
>> This seems like a bug in the kernel crypto API provider, what exactly it is?
>> What architecture?
>>
>> We have seen the same problem with Raspbery PI2 & NEON crypto driver
>> (it was a bug in kernel code), I guess it is the same here.
>>
>> Milan
>>
>>> On 06.08.2015 14:19, Lars Winterfeld wrote:
>>>> Am 06.08.2015 um 12:38 schrieb Vasile Catalin-B50542:
>>>>> Does the underlying encryption layer (CryptoAPI) have to ensure the
>>>>> complete callbacks are called in the order the requests were submitted?
>>>> Are you thinking about parallelization or asynchronous processing?
>>>>
>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt at saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
> 
> -- 
> 
> CatalinVasile
> 
> Intern, DN-Software
> 
> FreescaleSemiconductor, Inc.
> 
> www.freescale.com
> 
> phone: 073-021-1938
> 
> e-mail: catalin.vasile at freescale.com <mailto:your.name at freescale.com>
> 
> *Freescale_Logo-nosemi_Lh_4c***
> 
> This e-mail, and any associated attachments have been classified as:
> 
> [ ] Public
> 
> [ ] Freescale Semiconductor Internal Use Only
> 
> [ ] Freescale Semiconductor Confidential Proprietary
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 


More information about the dm-crypt mailing list