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

[FSkal1]

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

[idata]

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.

[FSkal1]

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

[FSkal1]

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

[FSkal1]

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 , engine = 0x555555810460, encrypt = 1, buf_len = 0, oiv = '\000' , iv = '\000' ,

buf = '\000' , num = 0, app_data = 0x0, key_len = 16, flags = 0, cipher_data = 0x55555582d480, final_used = 0, block_mask = 15,

final = '\000' , 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 , engine = 0x555555810460, encrypt = 0, buf_len = 0, oiv = '\000' , iv = '\000' ,

buf = '\000' , num = 0, app_data = 0x0, key_len = 16, flags = 0, cipher_data = 0x55555582b330, final_used = 0, block_mask = 15,

final = '\000' , internal = 0x0}

Rgds.

Franz

[STEVEN_L_Intel]

Hi Franz,

This is good place to post questions and bug reports about the QAT OpenSSL Patch.

I am part of the development team working on the patch amongst other things so all feedback good or bad is welcome.

OpenSSH hasn't been an application we have been targeting so far, so you may have found a use case we have not tested against.

I am going to raise an internal defect to look at the issue you have highlighted.

The aim will be for someone to look into this further over the next two weeks.

Kind Regards,

Steve

[Natalie_Z_Intel]

Thanks for the input, SteveLinsell! We look forward to learning what you find! LynnZ.

[FSkal1]

Hi Steve,

some things to say,

i tested with asynch digest disabled but sych digest enabled.

Also, openssh doesn't use some special functions but stock do_cipher and a filled ctx.

the aes_128_cbc it will use from the openssl or the internal rjindael when enabled.

So, other vendors i'm testing right now, supply an engine (.so) which works out of the box.

I think, the lost iv ov seems to be in conjunction with loading another shared lib (qat_mem), since when disabling it, all works as expected.

I will wait then and test the kernel ipsec implementation.

Rgds.

Franz

[CarlosAM_INTEL]

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.

[FSkal1]

Hi Carlos,

sorry, but i was on vaction.

I don't know, if the new version (http://www.intel.com/content/www/us/en/embedded/technology/quickassist/downloads.html Intel® QuickAssist Technology: Downloads) will work with openssh.

I'm using the kernel ipsec framework which serves my purpose.

Give it a try and report back.

Rgds.

Franz

[CarlosAM_INTEL]

Hello FranzCC,

The compatibility between OpenSSH and QAT has been untested by Intel.

Please let us know if this information is useful to you.

Best Regards,

Carlos A.