linux 3.10 crash with crypto hardware assist,
Has anyone seen the following problem on Linux 3.10, or later Linux? If it is fixed, can anyone point out where the fix is? Thanks. Chemin We are running Android, based on Linux3.10. With our crypto hardware accelerator, and driver, algorithm of "authenc(hmac(sha1),cbc(aes))" is running well. With our hardware accelerator and algorithm of "rfc4309(ccm(aes))", it is running fine too. We start testing extended sequence number recently. ip xfrm state is set with flag esn and replay-window 256. System crashes shortly, after the first couple of packet transmits. We try to run the same test with flag esn and replay-window 256 with algorithm of "rfc4309(ccm(aes))", it still runs fine with hardware accelerator. We go back to the same algorithm of "authenc(hmac(sha1),cbc(aes))" but without hardware accelerator. This time, it runs fine. The crypto hardware driver is agnostic to esn. Without esn, it is running fine. So it is less likely driver is at fault. When it crashes, the stack dump looks like the following # ping 10.2.242.93 -I 192.168.2.10 PING 10.2.242.93 (10.2.242.93) from 192.168.2.10: 56 data byt 329.068077] Unable to handle kernel NULL pointer dereference at virtual address 0008 [ 329.079579] pgd = c0004000 [ 329.082277] [0008] *pgd= [ 329.085844] Internal error: Oops: 5 [#1] PREEMPT SMP THUMB2 [ 329.091390] Modules linked in: ota_crypto ath_pktlog(PO) umac(O) ath_dev(PO) ath_dfs(PO) ath_rate_atheros(PO) ath_hal(PO) adf(PO) asf(PO) evbug [ 329.104228] CPU: 3 PID: 247 Comm: kworker/3:1H Tainted: P O 3.10.84-perf-gbc40dee-35160-g0d54083 #1 [ 329.114126] Workqueue: qcrypto_seq_response_wq seq_response [ 329.119678] task: c94fd080 ti: c97be000 task.ti: c97be000 [ 329.125062] PC is at scatterwalk_map_and_copy+0x1e/0x98 [ 329.130272] LR is at authenc_esn_geniv_ahash_done+0x29/0x3c [ 329.135824] pc : []lr : []psr: 2033 [ 329.135824] sp : c97bfe98 ip : fp : c0c189e4 [ 329.147282] r10: c91585ac r9 : c9158564 r8 : c0b163c8 [ 329.152490] r7 : r6 : 0001 r5 : r4 : 271ae748 [ 329.158999] r3 : c0b6155c r2 : r1 : r0 : [ 329.165510] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment kernel [ 329.172977] Control: 50c5787d Table: 1267c06a DAC: 0015 [ 329.178706] [ 329.178706] PC: 0xc02cd3b2: [ 329.182958] d3b0 f3c243e2 3201020b 1b2c441d bf284294 42b44614 4634bf28 ff5ef7ff 46394605 [ 329.191117] d3d0 0f00f1b8 4629d101 46224638 f02a4427 4628fadf fb62f645 5004f8d9 464842a6 [ 329.199277] d3f0 f04f4641 eba60201 44250604 5004f8c9 e9ddd1cd e9dd3400 e9dd5602 b0067804 [ 329.207436] d410 8200e8bd 4506e96d 8e04e9cd 38c8f246 08b1f2cc 6702e9cd f8d8b084 94034000 [ 329.215596] d430 688cb33b 91012600 b17446b6 1935684f 970242aa 680cd310 d40807a4 b32c698c [ 329.223756] d450 462e3110 2c009101 f7ffd1f0 f8deff27 21004008 e7f5462e a9014417 461a1bbe [ 329.231915] d470 96029b0a ff86f7ff 990aa801 f7ff2200 9a03ff5d 3000f8d8 d10d429a e9ddb004 [ 329.240075] d490 e9dd4500 b0046702 8100e8bd 462e6909 0103f021 e7d5688c ffacf661 f2474608 [ 329.248236] d4b0 f2cc21d8 f72b0172 bf00b85b 4504e96d f24f460c f1040120 f2cc0228 e9cd0189 [ 329.256397] [ 329.256397] LR: 0xc02df07d: [ 329.260650] f07c e7cf0149 ebc96cb2 46500308 e9d46961 6ae56702 65a36992 6aa36561 64e76a21 [ 329.268809] f09c 652264a6 e9c46665 68d31317 46014798 bf00e7b5 4e02e96d f5004604 f7ed708c [ 329.276968] f0bc f504fa6b f7ed7080 4620fa67 4e00e9dd f6fdb002 bf00bea1 4504e96d e9cd460d [ 329.285127] f0dc 68c46e02 6923b082 b9496c1a 44222601 f8d26a1b 6ce100cc 96006c22 f98cf7ee [ 329.293287] f0fc 462968a3 b0024620 4500e9dd 6e02e9dd 4718b004 3406e96d 5602e9cd 4606460d [ 329.301448] f11c 7e04e9cd e9d26902 6eda4310 f1034404 34ac0140 69d74620 681b6121 b1284798 [ 329.309608] f13c 3400e9dd 5602e9dd bd80b004 01acf106 f1066c72 eb010350 46200147 692361e3 [ 329.317768] f15c 0707ea21 622761a2 f8d66972 60e610a4 60a1402a f8536162 47983c3c d1df2800 [ 329.325927] f17c 46206cf1 62276c33 e9c46922 69733106 10a8f8d6 402b60e6 616360a1 3c3cf852 [ 329.334086] [ 329.334086] SP: 0xc97bfe18: [ 329.338340] fe18 0001 c0b2cf80 c1b9f4c0 c0b2cf80 6013 271ae748 c02cd432 2033 [ 329.346500] fe38 c97bfe84 c0b163c8 c9158564 c91585ac c06172f5 [ 329.354658] fe58 c0b6155c 271ae748 0001 c0b163c8 c9158564 [ 329.362819] fe78 c91585ac c0c189e4 c97bfe98 c02df0fd c02cd432 2033 [ 329.370978] fe98 c9158564 8b43 0001 271ae748 cab26540 0001 [ 329.379139] feb8 c0c18950 c02df0fd 0001 c02d087f c0c189fc 0001 c03bc4c7 [ 329.387299] fed8 c0c189ec c0c189e0 c1ba1540 c0c189ec c97b4e80 c0b6ada0 c1ba1540 c1ba6800 [ 329.395458] fef8 0001 c1ba1540 c97be008 c01458ab c97bff20 [ 329.403619] [ 329.403619] FP: 0xc0c18964: [ 329.407871] 8964 0100 01010001
[QUESTION] authenc(hmac(sha 1 or 256),cbc(aes)) fallback
Herbert: Did anyone report problem on the area of authen(hmac(sha1), cbc(aes)) fallback, since linux 3-10? I am working on android linux 3-10. Our hardware does not support aes 192. I am following the example from picoxcell_crypto.c. In the cra_init, driver does the following to allocate a fallback crypto_aead. tx-sw_cipher = crypto_alloc_aead (alg-cra_name, 0, CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK); I define two xfrm. They are as such: #ip xfrm state show src 10.2.243.105 dst 10.2.243.29 proto esp spi 0x0701 reqid 0 mode transport replay-window 0 auth-trunc hmac(sha256) 0x8d967d88f6caa9d714800ab3d48051d63f73a3120102030405060708090a0b 96 enc cbc(aes) 0x7d8adc5f52e6b2291f27a4c0384624a7 sel src 0.0.0.0/0 dst 0.0.0.0/0 src 10.2.243.29 dst 10.2.243.105 proto esp spi 0x0601 reqid 0 mode transport replay-window 0 auth-trunc hmac(sha256) 0x8d967d88f6caa9d714800ab3d48051d63f73a3120102030405060708090a0b 96 enc cbc(aes) 0x7d8adc5f52e6b2291f27a4c0384624a7 sel src 0.0.0.0/0 dst 0.0.0.0/0 It seems the 2nd xfrm-__crt_alg is pointing to software implementation algorithm, instead of our driver. xfrm state is aes128 ciphering and the sw implementation is not supposedly to happen. As the result of 2nd xfrm pointing to software implementation, one direction of traffic (for the 2nd xfrm) is aeaded by software implementation. Does it make sense? I put trace in crypto modules. After ip xfrm state add command for both xfrm, the trace displays as included at end of this mail. I put some notes, with indentation as ==, in time [132.061018], [ 132.067901], [ 132.104352], [ 132.335460] , [ 132.370316] , [ 132.39] ,[ 132.381226] [ 131.951846] crypto_alg_mod_lookup name hmac(sha256) type 408 mask 40e [ 131.957094] crypto_alg_lookup hmac(sha256) 408 40e [ 131.962022] crypto_alg_lookup hmac(sha256) 408 40e alg (null) [ 131.971769] crypto_larval_lookup. request_module hmac(sha256) [ 131.976593] crypto_alg_lookup hmac(sha256) 408 40e [ 131.981335] crypto_alg_lookup hmac(sha256) 408 40e alg (null) [ 131.987259] crypto_larval_lookup. crypto_larval_add hmac(sha256) 408 40e [ 131.994088] crypto_alg_mod_lookup name sha256 type 409 mask 40f [ 131.999755] crypto_alg_lookup sha256 409 40f [ 132.004236] crypto_alg_lookup sha256 409 40f alg c08308ac [ 132.009544] return larval c08308ac [ 132.013128] return alg cbdcf62c [ 132.016257] crypto_alg_mod_lookup name cbc(aes) type 404 mask 40c [ 132.022130] crypto_alg_lookup cbc(aes) 404 40c [ 132.026756] crypto_alg_lookup cbc(aes) 404 40c alg e73be008 [ 132.032286] return larval e73be008 [ 132.035825] crypto_alg_mod_lookup name authenc(hmac(sha256),cbc(aes)) type 403 mask 40f [ 132.043571] crypto_alg_lookup authenc(hmac(sha256),cbc(aes)) 403 40f [ 132.050123] crypto_alg_lookup authenc(hmac(sha256),cbc(aes)) 403 40f alg cbb1d008 [ 132.057571] return larval cbb1d008 [ 132.061018] crypto_alloc_aead authenc(hmac(sha256),cbc(aes)) 3 f cbb1d008 == for the first xfrm, alg is 0xcbb1d008 [ 132.067901] crypto_alg_mod_lookup name authenc(hmac(sha256),cbc(aes)) type 403 mask 58f == driver does crypto_alloc_aead() with CRYPTO_ALG_NEED_FALLBACK (0x100) set in mask. [ 132.075708] crypto_alg_lookup authenc(hmac(sha256),cbc(aes)) 403 58f [ 132.082200] crypto_alg_lookup authenc(hmac(sha256),cbc(aes)) 403 58f alg (null) [ 132.091553] crypto_alg_lookup authenc(hmac(sha256),cbc(aes)) 403 58f [ 132.096887] crypto_alg_lookup authenc(hmac(sha256),cbc(aes)) 403 58f alg (null) [ 132.104352] crypto_larval_lookup. crypto_larval_add authenc(hmac(sha256),cbc(aes)) 403 58f == add larval for sw implementation algorithm. [ 132.112737] crypto_alg_mod_lookup name hmac(sha256) type 40a mask 40c [ 132.118928] crypto_alg_lookup hmac(sha256) 408 40c [ 132.123862] crypto_alg_lookup hmac(sha256) 408 40c alg cbb1d910 [ 132.129788] return larval cbb1d910 [ 132.133236] crypto_alg_mod_lookup name cbc(aes) type 404 mask 48c [ 132.139160] crypto_alg_lookup cbc(aes) 404 48c [ 132.143738] crypto_alg_lookup cbc(aes) 404 48c alg (null) [ 132.152931] crypto_larval_lookup. request_module cbc(aes) [ 132.157399] crypto_alg_lookup cbc(aes) 404 48c [ 132.161802] crypto_alg_lookup cbc(aes) 404 48c alg (null) [ 132.167378] crypto_larval_lookup. crypto_larval_add cbc(aes) 404 48c [ 132.173840] crypto_alg_mod_lookup name aes type 401 mask 40f [ 132.179273] crypto_alg_lookup aes 401 40f [ 132.183415] crypto_alg_lookup aes 401 40f alg c0831074 [ 132.188560] return larval c0831074 [ 132.192121] return alg cbdcf200 [ 132.195245] crypto_alg_mod_lookup name cbc(aes) type 404 mask 8c [ 132.201033] crypto_alg_lookup cbc(aes) 4 8c [ 132.205406] crypto_alg_lookup cbc(aes) 4 8c alg cbdcf200 [ 132.210669] return larval cbdcf200 [
RE: [QUESTION] multi-core, multi-crypto, ipsec/udp out of order.
Herbert: Sorry, what is in-tree driver? This is Qcom crypto driver. It is part of android linux 3-10. I think Stanimir Varbanov is working on upstreaming the crypto driver. The driver version he cuts off, does static crypto engine assignment, i.e. crypto HW is assigned to a TFM on cra_init. That scheme is simple. But, under the same TFM, it does not take advantage of multiple crypto HW working in parallel. Later, we put in dynamic engine assignment per request, as described in the previous mail thread. I am trying to understand why we are seeing iperf server out of order message once we have different cores assigned to crypto irq affinity. Thanks. Chemin -Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Monday, June 02, 2014 8:47 AM To: Hsieh, Che-Min Cc: linux-crypto@vger.kernel.org; net...@vger.kernel.org; Steffen Klassert Subject: Re: [QUESTION] multi-core, multi-crypto, ipsec/udp out of order. On Fri, May 30, 2014 at 02:22:17PM +, Hsieh, Che-Min wrote: Hi! Herbert: In a system of multi cpu core, with multiple crypto hardware, different irq for each, is it possible the udp receive get out of order for the same tfm? Let us say, of the same tfm, driver distributes requests to any available crypto hardware. For the same tfm, driver re-sequences response before complete callout to the same arrival sequence of the requests. The complete callout is running at tasklet level of the system. Each irq is assigned to a different irq affinity cpu core to improve the performance. Therefore the iprecv and ipsec processing can be done by multiple cpu cores at the same time for the same tfm/udp. I am seeing the following - if I assign irq affinity to different cpu cores, iperf server of udp session displays receive out of order message. If I assign them to the same core, or take default, then message stops. The assignment is done by hand while the system is running, by updating /proc/irq/xxx/smp_affinity, where xxx is the irq number. This scenario is very repeatable. We are on linux-3.10. Does it make sense? Are we talking about an in-tree driver? If so which one? It's not certainly not meant to change packet ordering. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [QUESTION] Crypto queue handling
Herbert: It is nice to know that the request queue is per tfm. We are currently on android-3.10. I believe all the drivers under drivers/crypto/ don't follow this rule. At the minimum, our driver qcrypto does not. Other than backlogging function, does it break anything? How critical is it to fix the driver soon? Thanks Regards, Chemin -Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Herbert Xu Sent: Friday, May 30, 2014 5:31 AM To: Marek Vasut Cc: linux-crypto@vger.kernel.org; Arnd Bergmann; Pantelis Antoniou Subject: Re: [QUESTION] Crypto queue handling On Mon, May 26, 2014 at 05:58:19PM +0200, Marek Vasut wrote: Hello, I'm digging in crypto/algapi.c , in the crypto_enqueue_request() function. I don't quite understand how the backlog mechanism should work. According to [1], I suspect it should limit the amount of requests in the queue to $max_qlen and allow one more request to be enqueued into the $backlog ; and if there is more requests than $max_qlen, it should start dropping the requests ? Inspecting the code, I see these situations: 1) qlen max_qlen - The request is enqueued, qlen is increased , returns -EINPROGRESS 2) qlen = max_qlen - The crypto_enqueue_request() returns -EBUSY in this case 2a) request-flags has CRYPTO_TFM_REQ_MAY_BACKLOG unset = Request is not enqueued , qlen is not increased 2b) request-flags has CRYPTO_TFM_REQ_MAY_BACKLOG set = Request is enqueued , qlen is increased The queue is per-tfm. In this case you never want to share a tfm between two users that do not agree on whether to have backlog or not. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[QUESTION] multi-core, multi-crypto, ipsec/udp out of order.
Hi! Herbert: In a system of multi cpu core, with multiple crypto hardware, different irq for each, is it possible the udp receive get out of order for the same tfm? Let us say, of the same tfm, driver distributes requests to any available crypto hardware. For the same tfm, driver re-sequences response before complete callout to the same arrival sequence of the requests. The complete callout is running at tasklet level of the system. Each irq is assigned to a different irq affinity cpu core to improve the performance. Therefore the iprecv and ipsec processing can be done by multiple cpu cores at the same time for the same tfm/udp. I am seeing the following - if I assign irq affinity to different cpu cores, iperf server of udp session displays receive out of order message. If I assign them to the same core, or take default, then message stops. The assignment is done by hand while the system is running, by updating /proc/irq/xxx/smp_affinity, where xxx is the irq number. This scenario is very repeatable. We are on linux-3.10. Does it make sense? Regards, Chemin -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
question about rfc404 support.
Herbert: Can you confirm the following. Thanks. Rfc2404 - The Use of HMAC-SHA-1-96 within ESP and AH For the support, I can't find any algorithm to be specified in the .craname of ahash_alg for Rfc2404. From http://www.freebsd.org/cgi/man.cgi?query=setkeysektion=8 it says the following : ALGORITHMS The following list shows the supported algorithms. The protocol and algorithm are almost completely orthogonal. The following list of authentication algorithms can be used as aalgo in the -A aalgo of the protocol parameter: algorithm keylen (bits) comment hmac-sha1 160 ah: rfc2404 That leads me to believe, from crypto driver stand point, there is no need to have a new algorithm for hmac-sha-1-96 support. Instead, the agent SW(such as ipsec) should use hmac(sha1), and do the truncation of digested data from 160 bits to 96 bits. I run a quick test. The input file to setkey command is defined as such flush; spdflush; add 10.2.243.75 10.2.243.29 ah 0x604 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A312; add 10.2.243.29 10.2.243.75 ah 0x605 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A314; spdadd 10.2.243.75 10.2.243.29 any -P in ipsec ah/transport//use; spdadd 10.2.243.29 10.2.243.75 any -P out ipsec ah/transport//use; I use tcpdump. Clearly I can see 24 bytes of AH header of the ipsec packets. The header has 12 bytes of fixed information - Next (1), Ah len (1) ,Reserved (2), Spi (4) ,Sequence (4), and Auth result. (12 bytes) Can you confirm the above? Thanks. Regards, Chemin -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Questions about the Crypto API
Garg: For any tfm, blkcipher or ablkcipher, they must return results in the order they were given. For a blkcipher which is synchronous, this is always true by definition since we return only after the result has been completed. For an async ablkcipher, this means that if you receive two requests on the same CPU, then the first request must be served and completed before the second request's completion can be initiated. Herbert, can you give further clarification: (*) This ordering of result is also true for others, such as aead and hashing, right? Can you confirm, or correct the following statements: (*)To perform hashing on a long data stream, it may come in multiple requests to the driver; in a sequence of one .init request, one or more than one .update requests, and lastly one .final request. In this sequence, a request has to be complete, before next one to be issued to the driver. Those requests should always come in the same struct crypto_async_request. Is this correct? If driver needs to maintain state variables for such (init, update, final), the state variables can be maintained in the request implementation context, instead of tfm context. Right? Thanks. Chemin -Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Marcelo Cerri Sent: Monday, August 12, 2013 9:49 AM To: Herbert Xu Cc: Hsieh, Che-Min; Garg Vakul-B16394; linux-crypto@vger.kernel.org Subject: Re: Questions about the Crypto API On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote: On Fri, Aug 09, 2013 at 01:09:12PM +, Hsieh, Che-Min wrote: Marcelo/Herbert: I believe It is. Herbert, please correct me if I am wrong. A single tfm is used as a user context to crypto, so to speak. But a user is not a thread. Let us use ipsec as example. For each security association (SA), it will take up a tfm. Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction. Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts. But only two tfm's are involved. I have seen this happening in our system with ipsec setup as described above. While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm. Yes you're absolutely right. Unless I've misunderstood Marcelo's question is different from what Garg was asking. Marcelo: The tfm, be it blkcipher or ablkcipher can always be used in parallel by the user on different CPUs. For example, IPsec may receive two packets on two CPUs through the same SA, in which case decryption will be carried out in parallel. So does that means that it's possible to keep data in the tfm's context that is the same for a single SA, such as the AES expanded key, but it's not possible to keep data that is specific for the current operation, such as an operation state that the driver might require? Actually I think that probably I have misunderstood the blkcipher interface, so here it is another question: is each encrypt/decrypt call a complete operation? I mean, I'm considering that I could always chain a series of calls to encrypt data in separated chunks, in a similar way that is done for the hash interface and because that I'm assuming that I would have to keep state between those calls if the device requires that. Garg: For any tfm, blkcipher or ablkcipher, they must return results in the order they were given. For a blkcipher which is synchronous, this is always true by definition since we return only after the result has been completed. For an async ablkcipher, this means that if you receive two requests on the same CPU, then the first request must be served and completed before the second request's completion can be initiated. Sorry for any confusion this might have caused. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Questions about the Crypto API
Thanks for Herbert response to my burning questions. Please see my follow on comments. Please correct me if my comments are not correct. You should use your own list element This is the conclusion I reached when I looked into our problem. I looked at other drivers and tailtos driver. I believe the only correct implementation is to use our own list, similar way as tailtos driver. Thanks for your confirmation. Our problem is like the following. In our current implementation, we follow most of other drivers, (or we were lazy like rest of people, and just took easy way out :-)). We use the async request list structure, and API to maintain the outstanding requests. We also develop a set of loadable modules, as test vehicle to test our driver. Our test module modeling after tcrypt, and testmgr, it is sitting in a loop, issuing various async request, and then wait_for_completion_interruptable(). So after issuing modprobe test_module to start a test, if I hit control C, kernel panic left to right, complaining about list broken As for an aborted wait, the user must guarantee that any memory associated with the request is not freed until the driver has called the completion function. IOW we don't currently provide a kill mechanism to the user. So the correct behavior, is, driver should not be aware of the aborted request above. It should always do completion callback. That means, after it accepts an async request (return with -EINPROGRESS), the request and the resource are guaranteed to the driver until driver finishes the requests, and do the completion callback. It is the requestor's responsibility to ensure this happening. See for example how we handle this in IPsec. Can you point to me a list of kernel module names that handle this. I can easily look into it for reference. . IOW we don't currently provide a kill mechanism to the user. Good. Tcrypt.c and Testmgr is only a bad example? Do you have a particular case where a kill mechanism would be useful (memory corruption caused by the user freeing the request early is just a bug)? I don't see a need of it. As long as the responsibility of each is well understood and observed. The crypto api to the driver is like a disk i/o request from above to a disk driver. To the driver, once it is requested, it should run to its completion. However, the driver implementation should always include a timeout function to make sure HW function properly. There is no hanging somewhere. I don't see too many people doing that (including us). Cheers, Chemin -Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Friday, August 09, 2013 9:21 PM To: Hsieh, Che-Min Cc: Marcelo Cerri; linux-crypto@vger.kernel.org Subject: Re: Questions about the Crypto API On Thu, Aug 08, 2013 at 02:04:05PM +, Hsieh, Che-Min wrote: Thanks for Marcelo and Herbert for the questions and answers. I have a few more questions related to the same subject of API. 1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do crypto_enqueue_request() to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests. You should use your own list element since this may interfere with the crypto API's own queueing mechanism, if any (meaning that even if in your particular case this field is unused by the time you see it this may change in future). 2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does? If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially. If the requester is using the async interface then in general the requester should not be sitting around waiting for it to complete. See for example how we handle this in IPsec. As for an aborted wait, the user must guarantee that any memory associated with the request is not freed until the driver has called the completion function. IOW we don't currently provide a kill mechanism to the user. Do you have a particular case where a kill mechanism would be useful (memory corruption caused by the user freeing the request early is just a bug)? Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo
RE: Questions about the Crypto API
Thanks for Marcelo and Herbert for the questions and answers. I have a few more questions related to the same subject of API. 1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do crypto_enqueue_request() to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests. 2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does? If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially. Chemin -Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Herbert Xu Sent: Thursday, August 08, 2013 1:02 AM To: Marcelo Cerri Cc: linux-crypto@vger.kernel.org Subject: Re: Questions about the Crypto API On Tue, Aug 06, 2013 at 11:16:12AM -0300, Marcelo Cerri wrote: Herbert, Let me include a few more questions. There are flags in several structures such as crypto_async_request, blkcipher_desc and crypto_tfm. How they are intended to be used? For example if I want to explicitly make a call that shouldn't sleep, should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures? And in which one? Since cryptographic methods can be called in softirq contexts, is the caller responsible for setting this flag correctly based on the context it is running? Yes, although MAY_SLEEP is mostly used by synchronous implementations since async drivers can simply return instead of sleeping. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: questions of crypto async api
Thanks for the answer. I have further question on the same subject. With regard to the commit in talitos.c, (attached at end of this mail), the driver submits requests of same tfm to the same channel to ensure the ordering. Is it because the tfm context needs to be maintained from one operation to next operation? Eg, aead_givencrypt() generates iv based on previous iv result stored in tfm. If requests are sent to different channels dynamically. And driver at the completion of a request from HW, reorders the requests completion callback, what would happen? Thanks in advance. Chemin commit 5228f0f79e983c2b39c202c75af901ceb0003fc1 Author: Kim Phillips kim.phill...@freescale.com Date: Fri Jul 15 11:21:38 2011 +0800 crypto: talitos - ensure request ordering within a single tfm Assign single target channel per tfm in talitos_cra_init instead of performing channel scheduling dynamically during the encryption request. This changes the talitos_submit interface to accept a new channel number argument. Without this, rapid bursts of misc. sized requests could make it possible for IPsec packets to be encrypted out-of-order, which would result in packet drops due to sequence numbers falling outside the anti-reply window on a peer gateway. Signed-off-by: Kim Phillips kim.phill...@freescale.com Signed-off-by: Herbert Xu herb...@gondor.apana.org.au -Original Message- From: Kim Phillips [mailto:kim.phill...@freescale.com] Sent: Friday, April 05, 2013 6:33 PM To: Hsieh, Che-Min Cc: linux-crypto@vger.kernel.org Subject: Re: questions of crypto async api On Thu, 4 Apr 2013 14:38:41 + Hsieh, Che-Min chem...@qti.qualcomm.com wrote: If a driver supports multiple instances of HW crypto engines, the order of the request completion from HW can be different from the order of requests submitted to different HW. The 2nd request sent out to the 2nd HW instance may take shorter time to complete than the first request for different HW instance. Is the driver responsible for re-ordering the completion callout? Or the agents (such as IP protocol stack) are responsible for reordering? How does pcrypt do it? Does it make sense for a transform to send multiple requests outstanding to async crypto api? see: http://comments.gmane.org/gmane.linux.kernel.cryptoapi/5350 Is scatterwalk_sg_next() preferred method over sg_next()? Why? scatterwalk_* is the crypto subsystem's version of the function, so yes. sg_copy_to_buffer() and sg_copy_from_buffer() - sg_copy_buffer()-sg_copy_buffer() - sg_miter_next()- sg_next() Sometimes sg_copy_to_buffer() and sg_copy_from_buffer() in our driver do not copy the whole list. We have to rewrite those functions by using scattewalk_sg_next() to walk down the list. Is this the correct behavior? sounds like you're on the right track, although buffers shouldn't be being copied that often, if at all. Kim -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
questions of crypto async api
If a driver supports multiple instances of HW crypto engines, the order of the request completion from HW can be different from the order of requests submitted to different HW. The 2nd request sent out to the 2nd HW instance may take shorter time to complete than the first request for different HW instance. Is the driver responsible for re-ordering the completion callout? Or the agents (such as IP protocol stack) are responsible for reordering? How does pcrypt do it? Does it make sense for a transform to send multiple requests outstanding to async crypto api? Is scatterwalk_sg_next() preferred method over sg_next()? Why? sg_copy_to_buffer() and sg_copy_from_buffer() - sg_copy_buffer()-sg_copy_buffer() - sg_miter_next()- sg_next() Sometimes sg_copy_to_buffer() and sg_copy_from_buffer() in our driver do not copy the whole list. We have to rewrite those functions by using scattewalk_sg_next() to walk down the list. Is this the correct behavior? Thanks. Chemin -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
