0

When I was at university I was taught that I could request memory to be locked when allocating it. That this would stop it being swapped to disk. This is not true as it will swap-out when a suspend to disk is done. (The lock bit is a request, it is intended for performance, not security, and should only be used if you know what you are doing.)

So I was wondering if there is a way to allocate secure memory. I had two ideas, but I can not see if they are implemented:

  • secure lock: will prevent hibernation, so could cause problems to the rest of the system, unless there is a way to signal the process, to tell it to release the memory. But then what if it does not.

  • request volatile/transient memory: I am using volatile to mean even more volatile than RAM as the system can just un-map the memory, without swapping, or warning. This could cause a memory fault, that the application must handle.

    Large allocations would be used for decryption caches, and could be un-mapped, but can also be rebuilt. For the pass-phrases, these would be stored in small allocations, in the hope that they will not be un-mapped (except for hibernation). If a pass-phrase is un-mapped then user interaction is needed.

Does anything like this exist, including other alternatives?

I am using Debian9 Gnu/Linux, but would also be interested in what other operating systems do.

  • Some systems allows for encrypting the swap partition. – Kusalananda Aug 16 '17 at 10:56
  • @Kusalananda this has some value, but then the sys-admin needs to type in a pass-phrase for swap when system comes-out of hibernation. and sys-admin needs to be trusted. – ctrl-alt-delor Aug 16 '17 at 11:02
  • 2
    If you don't trust someone with root access, then whatever thing you do will not be enough. – Kusalananda Aug 16 '17 at 11:22
2

With the sole exception of hibernation, mlock() is guaranteed to keep the memory in RAM on Linux. This can be pretty simply proven by calling malloc() to allocate a chunk of memory the same size as your free memory, calling mlock() on it, and then forcing every page to be faulted in (don't do this on a production system, it will trigger the OOM killer, and that may not choose your test program to reap). So other than hibernation, you can trust mlock().

Hibernation gets tricky, but there are ways to handle that partially. Assuming your threat model trusts the root user (and you kind of have to), you should be able to hook into systemd to block hibernation while you have sensitive data in memory. Keep in mind that this isn't perfect, but it's probably the closest you can get. Alternatively, I think you can register a hook to notify your program if hibernation is started and wipe your sensitive memory, but I'm not 100% certain about that.

Regardless though, you may be overthinking this.

If you're just writing generic software and have zero platform control (think something like GPG or OpenSSL), you should just assume your users know the risk, mlock() the appropriate areas of memory (or better yet, give the option to do so so that people with transient (think zram) or encrypted swap can opt out of the resource usage hit), and be done with it. Keep in mind also that while the kernel's native hibernation support is a security issue (and a very well documented one), userspace implementations (like µswsusp) do often have built-in encryption support.

If, however, you're dealing with something where you control the OS the software will run on, you can just build your own kernel with hibernate support disabled.

  • I want hibernation. Registering for notification of hibernation seems like a way to do it. – ctrl-alt-delor Aug 16 '17 at 16:03
0

Preventing memory from being swapped out is not terribly useful (except in the kernel). The threat you're concerned with is an attacker reading swapped-out data from the disk, bypassing the operating system. This means that the attacker has physical access to the disk. In practice, that means the attacker has physical access to the machine, so they can read the same information from the RAM. It is possible to extract data from a RAM chip that's been powered down for a few seconds — not very reliably, but enough of a concern that you shouldn't leave a computer lying around if it's recently had secret data in RAM.

As a programmer, don't go looking for some weird OS trick to prevent hibernation. Users will hate it because it will cripple their functionality without helping their security.

As a user, encrypt your swap space.

  • I was thinking that the program could zero the memory when done with it. If the OS took it then it would have to zero it, to make use of it. if it was a security feature then this memory would also me zeroed, when taken from the process, instead of swapped. Everything would hibernate as expected, but on resume, the process with this memory would receive a page fault. The process must deal with this. This would involve re-allocating the memory, asking the user for the pass-phrase, and decrypting the data again. – ctrl-alt-delor Sep 4 '17 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.