2016. február 27., szombat 2:11:53 UTC+1 időpontban m.sile...@gmail.com a következőt írta: > Hi, > > Am Donnerstag, 25. Februar 2016 14:03:52 UTC+1 schrieb clabbe.montjoie: > > On Thu, Feb 25, 2016 at 04:20:23AM -0800, txsanyix wrote: > > > 2016. február 17., szerda 18:16:09 UTC+1 időpontban txsa...@gmail.com a > > > következőt írta: > > > > Hi > > > > > > > > I have a Cubieboard2 device, is Allwinner A20 SOC, running and Armbian > > > > 5.00 with kernel 4.4.1. > > > > > > > > As in the latest version the sun4i-ss module is added, i tried the > > > > hardware crypto acceleration with my 2 TB LUKS encrypted HDD, with > > > > 256bit AES-CBC-PLAIN64 encryption. > > > > > > > > It was fast, but i noticed that when playing videos from that HDD, > > > > there are random errors coming from somewhere. As the same happened > > > > when streaming the video on DLNA, and SAMBA, i did some tests. > > > > > > > > As the HDD is also used for a backup storage, i compared the original > > > > files with the backup on the encrypted HDD, and the most of the bigger > > > > files were different. > > > > > > > > So i've unloaded sun4i-ss module with "rmmod sun4i_ss" and everything > > > > become OK, no video errors, the backup and the original files are > > > > identical. > > > > > > > > So there is something wrong with this module, as i see only the > > > > decryption side is faulty, the encryption seems to be OK. > > > > > > > > Any suggestions? > > > > > > I mean at first test, when i've noticed that the files are wrong, i've > > > copied some originial and overwritten the wrongly decrypted files. Then > > > i've compared them and were identical. But after a restart of cubieboard, > > > re-mount, re-check the diff showed differences again, probably because > > > first time the file is read from cache, and not from the disk. > > > > > > > Hello > > > > I have added sync/dropcache in my lukstest tool. > > But I still didnt trigger the problem. > > > > Regards > > > > LABBE Corentin > > so, I tried something else today and I did trigger the issue! > > I created a 5GB container file on an external harddrive with the same > settings your lukstest script does: > cryptsetup luksFormat --verbose -c aes-cbc-plain -h sha1 > --key-file=container.key --batch-mode /media/extdisk/container.img > (Of course I formatted and mounted it as well, etc.) > > Then I downloaded a Debian DVD image file to the mounted encrypted container: > wget > http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-dvd/debian-8.3.0-amd64-DVD-1.iso > I then compared the md5sum and sha512sum of the downloaded file with the ones > Debian provides: > http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-dvd/MD5SUMS > http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-dvd/SHA512SUMS > > And the checksums DID NOT match! > > Now, of course that might have just been a transmission error. So, I went and > downloaded the same file again, but this time not to the encrypted container, > but directly to the external (unencrypted) harddrive. This time the checksums > matched. > > Then I copied the downloaded iso file from the unencrypted external disk to > the encrypted container. Checking the checksums of the file in the container > revealed that they don't match anymore. I repeated this a few times just to > see that the resulting checksums are always different. > > I tried with other iso files from Debian as well and it seems that it really > depends on the specific file whether the issue is triggered or not. I tried > e.g. the smaller netinst iso as well and with that everything works as it is > supposed to. > > Now, there are two more interesting observations: > 1) If I repeatedly call md5sum for the same file in the encrypted container, > it will always give a different checksum even though the file has not been > modified between the commands. So the decryption result really seems random. > > 2) The issue is not limited to decryption. The file is already corrupted > during encryption when it is created. I tested this by unloading the sun4i-ss > module after the file has been written to the encrypted container, remounting > the container and checking the checksum again (no match). > > I'm not done with all my testing yet. I will compile a Linux kernel 4.4.3 > image probably on Sunday and see if the error persists. But maybe this helps > already to at least reproduce the issue. > > Regards, > > Timo
So not my board is faulty. Same happens for me, with cryptotest-master apps i couldn't trigger the problem, only by copying bigger files. Sometimes it happens with 70 mbyte files too, but it's rare. With >1gb files, it's nearly sure. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
