Use hardware acceleration

[bill-mcgonigle]

I realize this is a big complex undertaking, and if there's a better place to put this, please say so, especially if somebody is already doing it.

Guardian Project LUKS should use hardware acceleration where possible, to save on power consumption and CPU use (vs. other processes running). Many of the target platforms include ways to accelerate AES with built in hardware. e.g.:

Older TI parts can use the C64x DSP for AES acceleration
http://ti.com/tool/c64xpluscrypto

TI's e-book platform (OMAP 36xx) has the M-Shield part with hardware AES.
http://focus.ti.com/pdfs/wtbu/SWPT045.pdf

Newer ARMv9 chips have AES instructions natively.

It may mean we need patches for Linux (I know Intel AES and Via Padlock are currently supported) which isn't trivial and could take a while to trickle down, but one must start somewhere.

[eighthave]

As far as I know, ARMv7 is the most recent instruction set. Do you mean ARM9? Which ARM CPUs have this instruction? If gcc is aware of those AES instructions, it should be possible to make it compile using them. If it needs to be hand-coded assembler, I think that's a question for upstream.

[bill-mcgonigle]

Yes, you're right of course - ARMv7 - I was thinking Cortex A9. (ARM n00b, if it wasn't obvious)

Doing a bit more research, LUKS will use the linux cryptoAPI when it can. cryptoAPI OMAP2/3 acceleration for AES went into 2.6.37, was bugfixed for 2.6.38 it looks like, which seems to be in CM 7.1+. If it's in the Kconfig for CM, it should be used by LUKS. I didn't yet see ARMv7 native AES support in arch/arm/mm but I might have missed it. The CPU-native AES seems to be picked up by the LUKS 'fpu' driver. Something like the OMAP2/3 accelerator may be on-die but it looks like it needs to be coded up as a separate hardware device so it has its own driver. I don't think you'll need to -mtune=coretexa9 (e.g.) to get the native instructions when they show up.

This project might be best-served by ensuring that upstream is doing the right KConfig options, or perhaps selectively backporting new cryptoapi patches if they're far out of sync with upstream. Or, even engaging manufacturers to get on the ball if they haven't yet added their hardware to the linux cryptoAPI. That looks to be a bit tricky - some guys from Nokia wound up doing the OMAP AES work - I would have guessed TI would be the right people to talk to, but clearly not. I see that Intel added the x86 AES-NI code - something like that should happen for the armv7 code.

This would all be clearer if kernel.org wasn't down... I think the linux-crypto list archives would be helpful here.

Personally I'm waiting to carry a smartphone on a daily basis until I can encrypt it and still get decent battery performance, and if I'm not the only paranoid nut out there, the manufacturers might have incentive to make it possible.