10 Replies Latest reply on Sep 4, 2015 11:05 AM by Carlos_A

    Where to submit bug reports and questions about QAT openssl (demo) patch ?

    FranzCC Green Belt

      Hi,

      i read the source of the latest openssl patch and found out, that  there's a conversion bug from u_int to size_t.

      Taking a closer look, reveals, that there's a one or probably more bugs in the (demo) patches.

       

      BUG 1:

      AES-CBC-128 when using a standard program which is linked to libcrypto.

       

      when using openssl speed the aes-cbc key and blocklen ist 16

       

      Using a linked standard software the iv-len gets 32 bytes.

       

      Speed do.cipher:

      Cipher 419 means AES_128_CBC which has a fixed key and blocklen of 16 bytes.

       

      [qat_do_cipher_synch] --- do_cipher 0x7ffdf16e4f20 BEGIN, inl 16

      qat_do_cipher_synch: Input

      bb 4d 30 07 97 5c c6 03 - 47 5d 4f 1f ae e5 0f b7 (16 bytes !!!)

      [qat_do_cipher_synch] --- cipher type: 419

      qat_do_cipher_synch iv len is 16

      qat_do_cipher_synch: ctx->iv

      bb 4d 30 07 97 5c c6 03 - 47 5d 4f 1f ae e5 0f b7

      [qat_do_cipher_synch] performing with 16 bytes (iv-len=16)

      e_qat.qat_crypto_callbackFn: status 0 verifyResult 1

      [qat_do_cipher_synch] --- do_cipher END

       

      Buggy call when using standard software:

      This software, like openssl uses u_int as block and key len. So, IMHO, the conversion from u_int to size_t is simply WRONG.

      The buggy qat engine call when using a STANDARD Software linked to openssl:

       

      [qat_do_cipher_synch] --- do_cipher 0x7f3260d28a20 BEGIN, inl 32 (WRONG, inl is 16 bytes on *ctx !!!)

      qat_do_cipher_synch: Input

      00 00 00 1c 0a 05 00 00 - 00 0c 73 73 68 2d 75 73 WRONG( should be 16 bytes !!!)

      65 72 61 75 74 68 2c d5 - e5 35 7f 9a 25 ba 3e ec

      [qat_do_cipher_synch] --- cipher type: 419 (AES-128-CBC)

      qat_do_cipher_synch iv len is 16

      qat_do_cipher_synch: ctx->iv

      00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 (Wrong allocation, NULL)

      [qat_do_cipher_synch] performing with 32 bytes (iv-len=16)  (Wrong, inl must be 16 not 32 bytes)

      e_qat.qat_crypto_callbackFn: status 0 verifyResult 1

      [qat_do_cipher_synch] --- do_cipher END

       

      Questions

      1.) Is there a working version of the openssl patch with no demo prefix ?

      2.) Does this mean, that the QAT engine is simply not working, or am i able to download a complete working software to evaluate and test ?

       

      Right now, i try a workaround with AES-128-CBC (if AES-128-CBC then inl = 16), but i think that the bug can only be solved by rewriting the whole openssl-async code to get portable code (u_int etc.)

       

       

      Rgds.

       

      Franz

        • Re: Where to submit bug reports and questions about QAT openssl (demo) patch ?
          Jimmy Manley Brown Belt

          Hi Franz,

           

          Welcome back to the Intel Embedded Community.

           

          We're working on this case, as soon as we have more information we'll let you know.

           

          Regards,

           

          Jimmy.

          • Re: Where to submit bug reports and questions about QAT openssl (demo) patch ?
            FranzCC Green Belt

            Hello,

            my workaround hasn't changed anything.

            Tested it using the stock aes_* fucntions (Rijndael and AES).

            So, e.g. i test openssh, which uses the builtin aes_* ciphers from openssl.

            Openssh can also be configured to use the internal Rijndael implementation.

            Both versions produce the same, wrong key and keylen.

            After the deactivation of the qat engine all is working properly, and the keylen etc. are all calculated correctly.

             

            Fyi.

             

            Rgds.

             

            Franz

            • Re: Where to submit bug reports and questions about QAT openssl (demo) patch ?
              FranzCC Green Belt

              Hello again,

              i compiled all with debugging enabled and did a gdb.

              after qat_cipher_init_synch, car key has a value.

              qat_cipher_init_synch (ctx=0x555555829748, key=0x55555582c3b0 "3\254cN\005\237\230\377P\204W\246\371&\336n\\\264\224\006\231\214E\371\240e\r0\310J\256y", iv=0x0, enc=0)

                  at qat_ciphers.c:773

               

              But when doing the cipher synch, in and out are empty:

              qat_do_cipher_synch (ctx=0x555555829990, out=0x55555582cf00 "", in=0x55555582bf70 "", inl=32) at qat_ciphers.c:830

               

              cipher_crypt has src "" and generates an invalid dest though.

              #6  0x0000555555590cc2 in cipher_crypt (cc=0x555555829988, seqnr=4103619960,

                  dest=0x55555582cf00 "\227ƫ\363\376\065O\317\024\225\304S4X\234\243\212\315?\340R\313\071\231XF?\362|s,9", src=0x55555582bf70 "", len=32, aadlen=4119280122, authlen=0)

                  at ../cipher.c:462

               

              Line 880 qat_ciphers.c produces 16 bytes of 00 then:

              DUMPL("ctx->iv", ctx->iv, EVP_CIPHER_CTX_iv_length(ctx));

              00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

               

              So, for my unterstanding, the problem happens between userspace and the kernel space via qat_mem.

              I think, the patch and the kernel space are work in progress but not able to handle normal usage with 3rd party apps, which work with normal openssl implementation  but not via the asnyc -> qat_mem -> icp_qa_al.

               

              Like i said, disabling engine qat works for me, with the same openssl source.

              I'm curious if there's a working reference implementation to test with standard 3rd party linux apps.

               

               

              Rgds.

               

              Franz

                • Re: Where to submit bug reports and questions about QAT openssl (demo) patch ?
                  FranzCC Green Belt

                  Hi again,

                  only a hint, but iov and iv are initialized with \000 but should have the values assigned.

                  Perhaps the qat_mem drops the values and initializes with an \0 terminator.

                   

                  reakpoint 2, qat_do_cipher_synch (ctx=0x555555829990, out=0x55555582cf00 "", in=0x55555582bf70 "", inl=32) at qat_ciphers.c:830

                  830    {

                  Current language:  auto

                  The current source language is "auto; currently c".

                  (gdb) p *ctx

                  $176 = {cipher = 0x7ffff4b89e00 <qat_aes_128_cbc>, engine = 0x555555810460, encrypt = 1, buf_len = 0, oiv = '\000' <repeats 15 times>, iv = '\000' <repeats 15 times>,

                    buf = '\000' <repeats 31 times>, num = 0, app_data = 0x0, key_len = 16, flags = 0, cipher_data = 0x55555582d480, final_used = 0, block_mask = 15,

                    final = '\000' <repeats 31 times>, internal = 0x0}

                  (gdb) p *out

                  $177 = 0 '\000'

                  (gdb) p *in

                  $178 = 0 '\000'

                   

                  But the key values has been initialzed right:

                  [qat_cipher_init_synch] --- called.

                  qat_cipher_init_synch (ctx=0x555555829748, key=0x55555582c3b0 "3\254cN\005\237\230\377P\204W\246\371&\336n\\\264\224\006\231\214E\371\240e\r0\310J\256y", iv=0x0, enc=0)

                      at qat_ciphers.c:773

                  773    }

                   

                  (gdb) p *ctx

                  $128 = {cipher = 0x7ffff4b89e00 <qat_aes_128_cbc>, engine = 0x555555810460, encrypt = 0, buf_len = 0, oiv = '\000' <repeats 15 times>, iv = '\000' <repeats 15 times>,

                    buf = '\000' <repeats 31 times>, num = 0, app_data = 0x0, key_len = 16, flags = 0, cipher_data = 0x55555582b330, final_used = 0, block_mask = 15,

                    final = '\000' <repeats 31 times>, internal = 0x0}

                   

                   

                   

                  Rgds.

                   

                  Franz

                • Re: Where to submit bug reports and questions about QAT openssl (demo) patch ?
                  Carlos_A Brown Belt

                  Hello Franz,

                   

                  Could you please let us know if you have any update related to this?

                   

                  Thanks in advance for your reply.

                   

                  Best Regards,

                  Carlos A.