On 02.03.2018 22:11, Gary R Hook wrote: > Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, > the result buffer with a known value and to test the buffer against that value at intermediate > steps. If the result buffer changes the operation is failed. > > My question is: why? > > What problem does this solve? Has this requirement existed all along, or is it new? > > I'm now seeing complaints for AES/CMAC and SHA in my driver. I have no problem updating the driver, > of course, but I'd like to better understand the precipitating issue for the commit. > > Mar 2 12:30:56 sosxen2 kernel: [ 60.919198] alg: No test for cfb(aes) (cfb-aes-ccp) > Mar 2 12:30:56 sosxen2 kernel: [ 60.924787] 367: alg: hash: update failed on test 3 for cmac-aes-ccp: used req->result > Mar 2 12:30:56 sosxen2 kernel: [ 60.946571] 367: alg: hash: update failed on test 4 for sha1-ccp: used req->result > Mar 2 12:30:56 sosxen2 kernel: [ 60.956461] 367: alg: hash: update failed on test 1 for hmac-sha1-ccp: used req->result > Mar 2 12:30:56 sosxen2 kernel: [ 60.966117] 367: alg: hash: update failed on test 4 for sha224-ccp: used req->result ahash req->result can be used in digit, final and finup hash operations. It should not be used in init and update (nor in export and import). There were some bugs in past, when drivers try to use req->result as theirs temporary storage. The bug comes up in some scenarios when caller reused ahash request and leaves in req->result undefined value, it can be NULL or container_of(NULL) or whatever was on stack -- Best regards, Kamil Konieczny Samsung R&D Institute Poland
