/dev/crypto opinions

3 posts in this topic

using /dev/crypto doesn't strike me as the fastest model for encryption. Simply because I my intuition would suggest that context switching, e.i. changing your memory maps and flushing your cache to enter kernel-space would be too much overhead. Even, I would presume, if a hardware crypto device were behind /dev/crypto. What is everyone's opinions on this? Should crypto be in userspace where it doesn't necessarily cause expensive context switches or should is it best to use /dev/crypto? Perhaps there could be a hybrid approach where your crypto framework uses user-space crypto until you reach some threshold where it then starts using /dev/crypto.

Share this post

Link to post

Share on other sites

using /dev/crypto doesn't strike me as the fastest model for encryption. Simply because I my intuition would suggest that context switching, e.i. changing your memory maps and flushing your cache to enter kernel-space would be too much overhead. Even, I would presume, if a hardware crypto device were behind /dev/crypto. What is everyone's opinions on this? Should crypto be in userspace where it doesn't necessarily cause expensive context switches or should is it best to use /dev/crypto? Perhaps there could be a hybrid approach where your crypto framework uses user-space crypto until you reach some threshold where it then starts using /dev/crypto.

No, your crypto should be in user-mode. This is basic POLA and secure system design: give everything as little privilege as possible. Kernel-mode code largely has permission to do anything. Why should your crypto system have that? Linux already has too much crap in kernel mode code, which is why it can't pass a high assurance security evaluation. You need a kernel that does the minimum to get the job done, then put the rest in user-space component style. Minimal TCB for best security. See Saltzer and Schroeder's paper or Daniel Bernstein's reflections on Qmail. You want to see how to do it right: Green Hills INTEGRITY (proprietary), QNX (proprietary), OKL4 (open-sourceD) or Perseus Security Architecture and MicroSINA (both open source). Minimal code with high privileges, componentized/layered functionality, strong information flow control, and medium to high assurance implementation/testing/analysis of requirements to design to code. If you want Linux, run it on top paravirtualized (ultra-fast on OKL4) with crypto isolated. Then, you have *some* security assurance. Put your crypto in kernel-mode in monolithic Linux kernel, then your existing attack surface just gets bigger. Keep it user mode. Use a mature library and protocol. As I tell aspiring security engineers, "tried and true beats novel and new."

Note: I'm a little buzzed but each point is supported by plenty of good evidence, esp. in high assurance circles. I apologize for any rough presentation issues ahead of time.