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 -- 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.
