On Sat, Jan 13, 2007 at 12:29:27AM +0100, Daniel de Kok wrote:
> 
> It feels wrong - there is a subsystem that provides useful abstraction for 
> cryptography, where cryptosoft is just one "provider" that can register 
> itself. Doesn't mixing xcrypt instructions sacrifice that abstraction?

I certainly don't think so.  I work with a lot of cryptographic hardware,
and there are basically two kinds: hardware that acts like separate
peripheral devices, that interfaces across the bus, needs a hardware
driver, etc; and hardware that just basically is special-purpose
instructions on the CPU you already have.  By your reasoning, we should
have separate "providers" for every piece of code in the system that
has multiple implementations tuned for specific processors in an
arch/ subdirectory.  But the fact is that fake peripheral device drivers
are not really a great abstraction for functionality that's actually
just additional slots in the instruction set of your CPU.

From my point of view, cryptographic implementations that interface to
the programmer and host like software ought to interface to opencrypto
via cryptosoft.  The other way creates a great deal of code duplication
and shoehorns functionality into an abstraction it just basically does
not fit, for no good reason.  The VIA crypto hardware does not actually
interface to the host like a separate hardware device and should not be
treated as one.  There are other CPUs that do crypto this way and I
would hate to see each one get its own reimplementation of cryptosoft
when _one_ "fake peripheral" provider implementation is really quite
enough.  And on the other hand, there are CPUs like the Alchemy ones
and some other MIPS parts aimed at networking applications, where the
crypto is separate functional units that you talk to like a bus
perhipheral.  Those _should_ get their own drivers, for the obvious
reason.  Motorola even sells different models in the Coldfire family
that do it each way...

That other stuff in the system should learn to use opencrypto is largely
a separate issue, though I agree with you.  But certainly the current
situation where cryptosoft uses one set of software transforms and
sys/crypto another is just wrong.

Thor