3

I need to be able to write a program that uses a secret value that I want to ensure never gets written to disk during a page swap. The value is securely entered when the program starts, and gets erased (by secure garbage collection) when it is no longer in use.

Can I tell linux not to write out a specific data value of a specific process to disk during a process switch or page swap? If not a single value, all variables/data for a specific process?

This question has been asked in part here:

https://stackoverflow.com/questions/578137/can-i-tell-linux-not-to-swap-out-a-particular-processes-memory

but there wasn't a satisfactory answer (a lot of "don't do this" type answers because the context wasn't explained).

I can't find any specific references to this problem elsewhere.

If the answer is 'no' then how can a program dealing with private information (e.g. GnuPGP amongst others) avoid having private keys hanging around on disk for some time (even if very short) leaving it prone to unauthorised snooping or forensic data recovery?

Community
  • 1
David Scholefield
  • 1,824
  • 12
  • 21

1 Answers1

3

You can use mlock, which were also mentioned in the question you referenced. From the man page:

mlock() and mlockall() respectively lock part or all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area.

But, this might not be enough because in case of a crash your program might leave a core dump which still includes these data. To get a much more detailed answer read Protecting sensitive data in memory.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I read that, but it seems to keep the entire process in memory and not just the data values. At a push (with some concern about memory size and the size of the entire process - think a runtime VM!) this would work, but I really want to just protect a very small piece of data only. – David Scholefield Oct 25 '15 at 11:43
  • OK, re-read that, I can see how you can lock selected memory blocks. Thanks for the clarification. – David Scholefield Oct 25 '15 at 12:22