Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.
I wish this were true, but it's a common misperception about mlock(). mlock() actually
cannot prevent keys from getting swapped, and it is pretty much guaranteed if you hibernate. It's one reason we recommend that high-security device disable swap space entirely -- it's not like you're going to need it running offline Armory, anyway, which has a very limited resource footprint. And hibernate as well, but I'm not sure hibernate works without a swap partition (good question, but go ahead and disable both).
Cryptographic security software often handles critical bytes like passwords or secret keys as data
structures. As a result of paging, these secrets could be transferred onto a persistent swap store medium, where
they might be accessible to the enemy long after the security software has erased the secrets in RAM and termi‐
nated. (But be aware that the suspend mode on laptops and some desktop computers will save a copy of the system's
RAM to disk, regardless of memory locks.)
Even worse, mlock() cannot guarantee that key material is not paged even outside of hibernate. mlock() is simply a very strong suggestion not to swap that key data, but if your really stress your system, it might happen. This is why Armory guarantees that key material stays in RAM self-destructs after 5 seconds of being unlocked. This pretty much guarantees that the user can't accidentally end up with key data in swap, unless they hibernate within 5 seconds of signing a transaction. Luckily, Armory enforces a 5 sec delay before showing you if a transaction succeeded
