[Botan-devel] RFC: memory locking

[Jack Lloyd]

Question: Do you use the memory locking abilities of Botan?

I've been looking at C++09 quite a bit and contemplating what parts
would be useful for Botan. And one thing that I've been considering
somewhat seriously is removing the allocator code and replacing the
current memory types with std::vector<byte> and std::array<byte, N>
(std::array would only be used internally, though: basically all
memory containers going into or out of the library would be
std::vectors)

In general my preference is strongly in favor of using standard
containers where possible, but previously that hasn't really been
considered an option due to the desire to support different locking
strategies.  However, supporting this code has a nonzero cost (not to
mention that using nonstandard containers implies extra effort people
to learn the library, that the containers and allocators are not as
efficient or useful as std::X and the libc heap, and that memory
allocation is not at all a core mission/goal of Botan and thus not
something it does particularly well). And I'm not even sure at this
point if any deployment of Botan actually uses the locking allocators,
so potentially we're carrying a great deal of extra code/cognitive
overhead which is being completely wasted. (If the allocators were
removed, Botan would still zeroize memory as necessary since that is
trivial to implement portably (though as always you never know what an
optimizing compiler might do)).

For the record, I consider locking strategies like this, including
mlock, as at best a hack to work around operating system
deficiencies. The only sane thing for an OS to do is zero out swapped
data pages on process exit. (Not to mention that swap encrypted with a
random key chosen at boot time is trivial to implement).

-Jack