VolatileFS - A full featured temporary RAM disk
- Frequently Asked Questions about VolatileFS.
- More information about our licensing scheme.
- Technical documentation for VolatileFS.
VolatileFS is a software able to create virtual file systems stored in the volatile memory.
VolatileFS is a temporary file storage facility working on GNU/Linux operating systems using FUSE. It is intended to appear as a mounted file system, but stored in volatile memory or SWAP files. VolatileFS is similar to a RAM disk or a TmpFS, which appears as a virtual disk file system, but working in user space and suporting a lot of features.
VolatileFS is a user-level application working at ring-3 and it doesn't require you to compile any kernel module or to patch in any way the kernel you're currently using. Once installed the software will work using FUSE to create userspace filesystems.
This software is able to show a certain disk size to the operating system and to dynamically increase the visible size of the disk as the amount of written files increases and the more space is required. VolatileFS can be configured to create SWAP files on-fly on the physical disk when a specified amount of real virtual memory (RAM) usage has been reached, it supports the automatic wiping of files on deletion and a transparent on-fly encryption system.
VolatileFS creates a temporary filesystem. It's a temporary filesystem, because all files are lost when the computer powers off, or when the filesystem gets unmounted. Every file is stored in the virtual memory and therefore the memory management has an important role in this software. VolatileFS supports an internal allocator, working without rely on the system allocator of the libc. This allocator is the EXTRAM allocator. With EXTRAM it's possible to tune many options related with the allocation of memory. It's also possible to allocate memory on the hard disk, from files. The EXTRAM allocator can create and delete on-fly SWAP files in user-space. This feature can be used to save the real virtual memory from your system and to use a temporary filesystem without caring much about the used RAM.
When a RAM disk or a TmpFS terminates, the content of the file system may be recoverable from the RAM memory and from SWAP partitions. A way to make the content of a RAM disk impossible to recover when it's no longer used, is by rewriting the previous used memory. Every time a file gets deleted from a temporary file system or when a volume is unmounted, a software can overwrite the used memory in order to destroy the deleted file(s). This is possible with VolatileFS. VolatileFS can automatically wipe the memory when a file is deleted from the file system. Alternatively, if the software is used with the EXTRAM allocator, it can wipe the entire memory area used to store the files only once: when the filesystem is unmounted or anyway when a memory block is returned to the operating system. The wiping of the memory is possible using the standard C allocator from the libc, and using the EXTRAM allocator.
- The libc allocator doesn't support in its internal architecture the native wiping of the used memory, and for this reason this feature works with wrapper APIs. These APIs slow down a lot the software. This is mostly due to the “realloc” function. When the “realloc” function is called, the old memory block has to be wiped after the new memory block has been allocated and initialized with the content from the old memory block. This procedure creates a lot of memory areas to wipe and to copy the data from/to every time a new byte is added to a file.
- The EXTRAM allocator, the proprietary allocator made by IZY Software, is able to wipe automatically the memory when it's freed. This allocator has been added build-in in VolatileFS. EXTRAM can wipe any object once it gets unreferenced and can also wipe all its own internal structures when they aren't anymore useful. If wiping each file isn't required EXTRAM is able to wipe giant memory blocks all at once, when all objects stored in them become unused and are returned to the operating system.
The wiping of the no-more-used memory isn't enough for some users of VolatileFS. For this reason, a built-in encryption feature (working with both allocators, libc and extram) has been added to the software.
VolatileFS can encrypt the files stored in memory. The software supports the following encryption schemes:
- AES128-CTR (the original AES operating in counter mode)
- AES256-CTR (Rijndael 256-CTR)
- XOR Obfuscation
Even if it's unusual for a temporary filesystem to encrypt its stored files, this feature has been requested and it's required in some environments. The main purpose is to protect the files from an analysis of the RAM memory. This is useful to strengthen the software against Cold boot attacks and thus to make the recover of the data harder. For a similar reason, data encryption is the best way to avoid the writing of plain text files to the SWAP partition or to the SWAP files created by the EXTRAM allocator.
If the operating system crashes or the power fails, the CPU turns off and all plain text files stored in the SWAP partitions are left written there without giving the time to VolatileFS to wipe the used memory areas. Those files can be kept in SWAP partitions or in SWAP files for ages, before they get randomly overwritten (if located in SWAP partitions) or automatically or manually deleted (in the case of SWAP files).
If all files are kept encrypted in the RAM memory the access to those files will be slower, but the recover of said files will be much harder.
VolatileFS doesn't need to have an input password to encrypt the files it stores until its termination. The software randomly generates a 128-bits key for the AES128 cipher or a 256-bits key for the AES256 cipher and the XOR Obfuscation. A cryptographically secure key is therefore generated when the software starts with the encryption feature enabled. Also, an independent 128-bits IV (Initialization Vector) is randomly generated per-file. It's unlikely for the software to use the same key twice, and it's unlikely for the software to encrypt two identical files in the same way even if they were created in the same session (this is due to different IVs).
When the temporary filesystem is unmounted all files in the filesystem will be lost, and this is why a password isn't required because nothing will be left to decrypt.
It's possible to test the software using the EXTRAM allocator and forcing it to always allocate the memory from SWAP files. You can start the software yourself with the switch -o extram_realmem_max=1. With this switch the software will always write to SWAP files in /tmp instead of to the RAM (it's possible to change the path, using another switch: -o extram_swapmem_directory=/home/user/temp). With the help of an hexadecimal editor you can read those files, usually named after the “MAP.” prefix and you'll find out that - indeed - they store the files stored inside the temporary filesystem. If you repeat this experiment with the encryption feature enabled, you'll see that nothing is stored in plain text.
The encryption feature encrypts everything related with a file: the content of the file, the filename and the metadata.
A cryptanalyst doing an extensive and expensive analysis of the non-wiped encrypted memory and/or the encrypted swap files (used for the storage of real files) won't be able to recover anything with an exception for the allocation structures used by EXTRAM. But if the allocation of these structures is made with the the external mode active, said structures won't be allocated together with the encrypted files. However by default the internal mode is used and from those structures it's possible to get an idea about the size of the biggest chunks of allocated or unallocated memory. Thus detecting the size of the biggest stored file, whose exact size cannot be determined because of memory alignment and due to the usage of a block cipher. A cryptanalysis of the software using the libc allocator hasn't be made, and for this reason it's recommended to use the EXTRAM allocator for paranoid usages. A probable implication of the libc allocator may be the leak of the linked list of memory blocks. In no way, these blocks can be wiped with the libc. You can wipe them only with EXTRAM. If either -o extram_wipe_nodes or the option -o extram_wipe_all is used (and the software terminates gracefully having a chance to wipe its own structures) nothing at all of readable will be left.
All encryption schemes are based either on the AES (Rijndael) or on the byte-per-byte XOR. Only the first cipher is cryptographically secure. The latter one, offers only a simple obfuscation with a short period of 2^8 (256) plus a 16 bytes independent scrambler per-file. With the XOR cipher you won't able to recover the content of a text file using the “strings” or the “grep” tool, but the XOR obfuscation is weak and it's actually possible to recover an encoded file. The only advantage of the XOR obfuscation over the AES is the speed: it's faster than the AES cipher; but again, unlike the AES it doesn't offer any real safety for the data.
In any case, when the program terminates normally, all used keys are wiped from the memory (including the expanded keys) and optionally also the encrypted files can be wiped on deletion or on software's termination using the features described in the previous chapter.
VolatileFS has been used:
- To create temporary file systems working in user space, and used in place of tmpfs.
- To create temporary file systems suitable for the temporary storage of decrypted files.