Le 16/03/2018 à 15:07, Horia Geantă a écrit :
On 3/16/2018 2:42 PM, Christophe LEROY wrote:
Le 16/03/2018 à 09:48, Horia Geantă a écrit :
For SEC 2.x+, cipher in length must contain only the ciphertext length.
In case of using hardware ICV checking, the ICV length is provided via
the "extent" field of the descriptor pointer.
Cc: <sta...@vger.kernel.org> # 4.8+
Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using
HMAC_SNOOP_NO_AFEU")
It looks like the issue comes more from commit fbb22137c4d9b ("crypto:
talitos - fix use of sg_link_tbl_len"), doesn't it ?
No, the first commit that breaks IPsec for SEC 2.x+ is the one I mentioned.
Today without your patch, IPsec works well on my mpc8321E. It was broken
by 549bd8bc5987 and fixed by fbb22137c4d9b.
But it seems the fix is not complete as it doesn't work yet in your case.
Afterwards, the refactoring of helper functions lead to current situation where
talitos_sg_map() is fed with "len" parameter that is used for two things:
-HW S/G table entries generation
-setting talitos pointer length
But in certain cases (like pointer nr. 4 - cipher in - for SEC 2.x+ IPsec),
talitos pointer length is only part of the total length, the other part being
set in the "extent" pointer field.
Currently talitos_sg_map() does not accommodate for this case.
In order to keep the fix to a minimum I've overwritten talitos pointer length:
-first talitos_sg_map() sets length to sg_link_tbl_len = cryptlen + authsize
-in case of SEC 2.x IPsec, length is corrected to cryptlen (while extent =
authsize)
I have proposed a v2 version of your patch which takes it into
talitos_sg_map() hence avoiding direct access to ptr[4] without using
the helpers.
Regards
Christophe
Regards,
Horia
