Open rfrht opened 6 years ago
Just wanting to weigh in here with some of my findings (using OpenSSL 1.0.2o and a Rock64 with RK3328).
For the past few weeks, I also struggled to access said module. I can confirm @rfrht s numbers, as in "whether or not the module is loaded does not make a difference".
After digging trough some ancient forum posts, it seem'd that openssl in particular would (should?) not be not able to access the module, as it resides in a different space (kernel space vs user space). So I gave cryptodev a shot. Build the kernel module, and rebuild openssl with cryptodev support. Still - nothing (at least - no difference with or without rk_crypto). However, cryptodev did something funny which is still interesting to consider:
Running the openssl speed -evp aes-128-cbc -engine cryptodev
yielded worse results for 16 and 64 byte ciphers, but much better results for cipher sizes 256 and up (we are talking 2500% improvement for 8192 ciphers here). Still, as things like openssh tend to use smaller ciphers, performance overall was worse with cryptodev. So what exactly is cryptodev doing here?
So, I then gave OpenSSL 1.1.0 a shot, as I read that some armv8 improvements were done, which should render the crypto module superfluous. But nope - regardless if using cryptodev or not, performance was - yet again - worse (this time all ciphers were worse).
So, this leaves me with a lot of question. It seems the kicker is that - even after several weeks experimenting - I was unable to properly access the module rk crypto module. So, anyone has any idea how to do so? Anything I missed?
I'm in the research stage of crypto acceleration for a Tinkerboard. I am interesting in using it from user space, too. I believe the manual for the RK3288 is located at Rockchip RK3288 Technical Reference Manual.
The current driver is having problems. It is producing incorrect results. @kernle32dll, this may expalin the performance problems you are seeing (the driver is borked). Also see [Bug] Rockchip crypto driver sometimes produces wrong ciphertext on the linux-crypto mailing list.
Can anyone confirm we cannot use the crypto from userspace? Or even better, can anyone find a userland C/C++ example of using the crypto acceleration? I'm happy to drop into inline assembly, if needed.
After digging trough some ancient forum posts, it seem'd that openssl in particular would (should?) not be not able to access the module, as it resides in a different space (kernel space vs user space).
Ping Andy Polyakov (@dot-asm). He may already know the limitations on the SoC.
Small offtopic question - did anyone succeed benchmarking 3288 crypto with mainline (5.15.64) kernel? I tried both with AF_ALG and cryptodev and both crash kernel/machine
I have built a kernel backporting 3288 Crypto accelerator (using a TinkerBoard) and I'm puzzled about how do I take advantage of the Crypto Engine.
I have done some OpenSSL tests and both shows no deviation from both with and without the module. See:
=== TESTING WITH THE ENGINE ===
=== REMOVING THE ENGINE ===
=== NOW TRYING A DIFFERENT OPENSSL TEST. STILL WITHOUT ENGINE ===
=== RE-INSERTING THE ENGINE ===
The test results are pretty much the same with and without the module.
Module information:
Any thoughts?