On 23.04.2010 17:44, Mario 'BitKoenig' Holbe wrote:
Hello,
Hi Mario,
the VIA Padlock engine comes without native XTS-AES support, thus compared to CBC-AES or ECB-AES XTS-AES performs quite bad on VIA CPUs because it calls the Padlock ACE for each single AESenc() operation. Using the Padlock's ECB-AES saves calls to the Padlock ACE and improves the XTS-AES performance by 30% and more even in a naive proof-of-concept implementation. The idea comes from DiskCryptor which does this since v0.9.583.106.
The same problem exists with the mv_cesa driver. I really like to have a solution for this as the performance of the system is mainly cripled by the hard disk encryption.
I have no idea where this should finally be implemented, since it slows down XTS on non-accelerated CPUs. Maybe a seperate xts-aes-padlock driver would make sense depending on how specific this is to VIA Padlock, i.e. how it performs on other non-XTS-capable accelerators.
I'm currently trying to get an understanding of the kernel crypto code, but my impression is that instead of breaking support with the synchronous API the better way would be to introduce asynchronous ciphers (e.g. acipher) that can be used transparently by crypto_template implementations to form an ablkcipher. In that way all crypto modes would be supported and accelerated through hardware, even if it doesn't provide an in-hardware implementation.
As I mentioned I'm new to the kernel API, so what is the opinion of experienced developers on this? Is that in reach of the current API architecture?
Please CC: me in replies, I'm not a member of the list. Mail-F'up2 should be set correctly.
Best regards, André Bubel -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
