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

[Michal Ludvig]

On Mon, 10 May 2004, James Morris wrote:

> On Mon, 10 May 2004, Michal Ludvig wrote:
>
> > It adds two new config options in the Cryptography section and if
> > these are selected, aes.ko is built with the support for PadLock ACE.
> > It can always be disabled with 'disable_via_padlock=1' module option
> > in this case, or if the PadLock is not found in the CPU, aes.ko
> > reverts to the software encryption.
>
> We really need a proper framework for this (i.e. per-arch hardware and asm
> support), not just hacks to the software AES module.

Yes, I know the presented approach wasn't too generic.

How about doing it in a device-like model? There would be different
providers for e.g. AES encryption and the kernel would autoload one of
them depending on say modprobe.conf settings. This way we'd have AES
implemented in software in one module and the PadLock AES in another.
By default the software versions would be used, but the user could choose
the one specific for their hardware.
Comments?

And how about the first patch for crypto/cipher.c? It extends the
interface for not only encryption/decryption of one block for given
algorithms, but also provides a way to do the transform of the whole
buffer in a given mode (ECB, CBC, ...). Is this acceptable in this form?
Should I do something similar for hash and compress functions to stay
consistent?

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/