Messages in this thread | | | Date | Wed, 12 May 2004 17:25:18 +0200 (CEST) | From | Michal Ludvig <> | Subject | Re: [PATCH 2/2] Support for VIA PadLock crypto engine |
| |
On Wed, 12 May 2004, James Morris wrote:
> On Wed, 12 May 2004, Michal Ludvig wrote: > > > In fact I believe that the hardware-specific drivers (e.g. the S/390 one) > > should be used in the cryptoapi as well and then the kernel should provide > > a single, universal device with read/write/ioctl calls for all of them. > > Not making a separete device for every piece of hardware on the market. > > Am I wrong? > > Providing a userspace API is an orthogonal issue, and really needs to be > designed in conjunction with the async hardware API. > > What I am suggesting is that you simply implement something like > des_z990.c so that C3 users can load crypto alg modules which use their > hardware.
Sorry, I overlooked that one as I was using the 2.6.5 source.
If I'd do it the same way and only implement .cia_encrypt/.cia_decrypt functions I wouldn't gain too much from the PadLock. The great thing is that it can encrypt/decrypt the whole block of data (e.g. the whole disk sector, 512B) at once using a selected mode (ECB, CBC, ...). With .cia_encrypt/.cia_decrypt the block chaining is done in software and the hardware is only called for encryption of a single block (e.g. 16B in case of AES) at a time. This is a big overhead and throws away most of the PadLock potential.
That's why I added .cia_ecb/.cia_cbc/... and modified cipher.c to call these whole-block-at-once methods instead of doing software-chaining+hardware-encryption. This way it's much much faster and I don't think that the changes to the cipher.c are somehow unclean.
Or can I achieve the same without extending the API?
Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |