Re: [PATCH 2/2] Support for VIA PadLock crypto engine

From: Michal Ludvig
Date: Wed May 12 2004 - 10:26:09 EST

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 -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at