Failure on XTS 128 rand test, for ARM arch #130
Labels
No labels
announcement
bug
duplicate
enhancement
help wanted
invalid
Next release
question
sighting
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-intel/isa-l_crypto#130
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Compiling the library with the extra tests (make test), results in a failure, on ARM architecture, on AES-XTS-128
./aes/xts_128_rand
aes_xts_128 enc/dec rand test, 10 sets of 1048576 max: ...........fail rand 0, size 308598
Can anyone check?
Can you tell me what hardware and compiler you are using?
I have tested on both kunpeng and Yitian and have not found this issue.
I tested with the latest code and found that there is indeed a problem. I will locate it further.
I think I may have found the problem. Here's the code from
aes/aarch64/xts_aes_common.S:In inplace mode, when the ciphertext/plaintext's tailcnt != 0, first, the
tailcntoflastblkis loaded totmpw, and then the address ofoutpis written. Note that in the inplace mode,inpandoutphave the same memory address. Therefore, the modification also changes the internal value ofinp. As a result, the value ofinploaded below is changed. As a result, the lasttailcntalso has an error. We can use the final result by comparing dt, and we can see that the mismatch is exactly in the tailcnt section:So how do we fix it?
We should avoid the content pointed by inp being modified. We find that
inpis mainly used for load, whileoutpis used for store. So we just need to switch the order of the two instructions, because they do not have data dependency, as follows:After the modification, the test can be passed.
Great! Could you send a PR with this fix? Thanks!
OK
I submitted a PR, but it was detected that I didn't sign-off, but I did, and the commit ID printed by CI's check_format.sh is different from the commit ID of my commit.
Thanks @chenxuqiang. I fixed the workflow already.
I re-triggered the workflow, and now it's passable. thanks @pablodelara
This is now fixed thanks!