On Thu, May 03, 2007 at 08:47:44AM -0600, Jordan Crouse (jordan.crouse@xxxxxxx) wrote: > On 03/05/07 23:49 +1000, Herbert Xu wrote: > > Evgeniy Polyakov <johnpol@xxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
