Hi Francis,
This has similar checkpatch issues + being split into multipart message
as your other patch.
Also, I think this patch should be split up in two, as there are two
issues you are fixing; the bad pointer issue (which I think you only
fixed partially, also the in->sgl has similar problem), and the missing
output IVI. Why is this needed btw, I have never faced the requirement
to update the IVI on the ahash request? Any crypto test cases I have ran
just work fine without this bit.
-Tero
On 22/03/18 16:58, Francis Le Bourse wrote:
Hello,
omap_aes_(cbc/ctr)(encrypt/decrypt) don't return the updated IV, add the
code to do just that at the end of the operation.
In omap_aes_done_task(), omap_crypto_cleanup() is called with:
omap_crypto_cleanup(&dd->out_sgl, dd->orig_out, 0, dd->total_save,
FLAGS_OUT_DATA_ST_SHIFT, dd->flags);
this ends up in freeing the part of the omap_aes_dev structure starting
at the address of the out_sgl member.
As the memory released is soon reused the kernel crashes at the next
encrypt/decrypt call:
[ 334.559643] Unable to handle kernel paging request at virtual
address 30627375
[ 334.566922] pgd = c0004000
[ 334.569650] [30627375] *pgd=00000000
[ 334.573252] Internal error: Oops: 5 [#1] SMP ARM
Entering kdb (current=0xee5fb0c0, pid 89) on processor 1 Oops: (null)
due to oops @ 0xc0b36a20
CPU: 1 PID: 89 Comm: 4b500000.aes-en Tainted: G C
4.14.13-ti-r25 #55
Hardware name: Generic DRA74X (Flattened Device Tree)
task: ee5fb0c0 task.stack: ee782000
PC is at omap_aes_crypt_dma+0x234/0x58c
LR is at irq_work_queue+0x14/0x90
pc : [<c0b36a20>] lr : [<c0256020>] psr: 60080013
sp : ee783e48 ip : 00000007 fp : ee783eac
r10: eba7f740 r9 : eba7f740 r8 : ee70d380
r7 : 00000001 r6 : c011a320 r5 : c1504dc8 r4 : ee70d310
r3 : 5c40a269 r2 : 5c40a269 r1 : 00000000 r0 : 30627375
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: ad69c06a DAC: 00000051
CPU: 1 PID: 89 Comm: 4b500000.aes-en Tainted: G C
4.14.13-ti-r25 #55
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c0d881f8>] (__dabt_svc) from [<c0b36a20>]
(omap_aes_crypt_dma+0x234/0x58c)
[<c0b36a20>] (omap_aes_crypt_dma) from [<c0b36fa0>]
(omap_aes_crypt_dma_start+0x228/0x400)
[<c0b36fa0>] (omap_aes_crypt_dma_start) from [<c0b3720c>]
(omap_aes_crypt_req+0x94/0x128)
[<c0b3720c>] (omap_aes_crypt_req) from [<c073bbf4>]
(crypto_pump_work+0x278/0x2f8)
[<c073bbf4>] (crypto_pump_work) from [<c016665c>]
(kthread_worker_fn+0x11c/0x20c)
[<c016665c>] (kthread_worker_fn) from [<c01664f4>]
(kthread+0x170/0x178)
[<c01664f4>] (kthread) from [<c0108fa8>] (ret_from_fork+0x14/0x2c)
Here the call should be omap_crypt_cleanup(dd->out_sg, ...);
A similar issue exists in omap-des.c.
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
