Re: Testing the geode-aes driver with the tcrypt module completely freezes the machine

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Thu, May 03, 2007 at 08:47:44AM -0600, Jordan Crouse (jordan.crouse@amd.com) wrote:
> On 03/05/07 23:49 +1000, Herbert Xu wrote:
> > Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > 
> > > Hm, driver does not perform encryption in-place at all.
> > > Since we did not hear from AMD quite for a while, could you please
> > > remove src==dst check in geode_aes_crypt() and run tests again.
> > > If it is software protection against hardware bug, I doubt such hardware
> > > should be used at all...
> >
> > I agree.  Jordan, could you please see if this can be fixed up?
> 
> On older versions of the chip, in-place encryption was not possible, even
> though there was no hardware protection against it.  I can't remember
> if the newer chip version can handle in place encryption or not.
> 
> I missed out on the context of this thread - does the tcrypt demand 
> in-place encryption?

Majority of the in-kernel crypto users require in-place crypto
processing. The only way to fix this I see is to allocate a buffer, copy
data and then perform crypto processing. But I seriously doubt it will
be faster then software encryption/decryption on that processor.

Test for possibility for in-place encryption can be done in module load
time and in case of failed crypto processing driver should fail into
alternative (with allocation) ecryption way (at least similar check I
perform in hifn module).

> Jordan

-- 
	Evgeniy Polyakov