Hey, to be honest I didn't realize it, since there's no indication or inprint on the website. And without trying it myself, i was assuming that the proximity to the RHEL-branch-off point in fedora should at least nudge you in the right direction :-) Sorry i can not be of more assistance for the lack of actual kirkwood hardware. Fiddling around with an embedded freescale core at the moment...
Greets, Thomas -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Gordan Bobic Gesendet: Freitag, 22. Mai 2015 16:35 An: [email protected] Betreff: Re: [RedSleeve-Users] Crypto Offload LOL! You do realize that I wrote that article, right? :) Back then it seemed to work, but that was years ago. Gordan On 2015-05-22 15:30, Thomas Göttgens wrote: > HI, > > this should help you go on... the findings are based on fc13, which is > roughly a bit newer than RHEL6. > > http://www.altechnative.net/2011/05/22/hardware-accelerated-ssl-on-marvell-k > irkwood-arm-using-openssl-on-fedora/ > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Gordan Bobic > Gesendet: Freitag, 22. Mai 2015 14:52 > An: [email protected] > Betreff: [RedSleeve-Users] Crypto Offload > > Hello, all. > > In preparation for making mantis and wiki more publicly accessible, > I am getting SSL certs sorted out for those services. Due to the > fact that the servers are running on an Marvell Kirkwood with an > asynchronous crypto offload engine, I would really rather like > to use that, because with it crypto is effectively free, and > without it it's expensive. > > So last night I rebuilt OpenSSL with -DHAVE_CRYPTODEV > (-DUSE_CRYPTODEV_DIGESTS seems to cause various things to > complain and break, so I skipped that for now), and everything > works OK, right up to the point where something tries to use an > algorithm that can be offloaded (such aes-128-cbc), at which > point things fail almost completely silently. For example, sshd > with verbose and debug logging levels only reports one single > line regarding the problem: > > fatal: evp_crypt: EVP_Cipher failed > > Specifying any non-offloadable algorithm works fine (albeit > as slowly as usual). > > That error appears to be getting emitted by OpenSSH sshd > rather than OpenSSL or Cryptodev. The relevant bit of code > is in OpenSSH's cipher.c file: > > void > cipher_crypt(CipherContext *cc, u_char *dest, const u_char *src, u_int > len) > { > if (len % cc->cipher->block_size) > fatal("cipher_encrypt: bad plaintext length %d", len); > if (EVP_Cipher(&cc->evp, dest, (u_char *)src, len) == 0) > fatal("evp_crypt: EVP_Cipher failed"); > } > > EVP_Cipher function is part of OpenSSL, declared in: > crypto/evp/evp.h: > int EVP_Cipher(EVP_CIPHER_CTX *c, > unsigned char *out, > const unsigned char *in, > unsigned int inl); > > and defined in: > crypto/evp/evp_lib.c: > int EVP_Cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned > char *in, unsigned int inl) > { > #ifdef OPENSSL_FIPS > FIPS_selftest_check(); > #endif > return ctx->cipher->do_cipher(ctx,out,in,inl); > } > > So it would appear that > ctx->cipher->do_cipher(ctx,out,in,inl); > returns 0. > > The most annoying part is that doing this in two separate sessions > works: > Server session: > openssl s_server -accept 1234 -nocert -cipher PSK-AES128-CBC-SHA -psk > 12345 > > Client session: > openssl s_client -connect localhost:1234 -cipher PSK-AES128-CBC-SHA > -psk > 12345 > > > What comes in on the client, comes out on the server, and the crypto > engine interrupt count (grep mv_crypto /proc/interrupts) ticks up as > expected. > > So the the basic crypto offload part seems to work just fine. > > At that point I ran out of functioning brain cells last night. > > I have not yet tried it with mod_ssl, which may yet turn out to work > fine, but ssh is just as valid a use case and was easier to test. > > Has anyone else here fought cyptodev with any success and chased > things further toward something resembling a conclusion? > > Gordan > _______________________________________________ > users mailing list > [email protected] > http://lists.redsleeve.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] > http://lists.redsleeve.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
