Source Hibernation Exposes Vulnerabilities with Software Encryption

Where windows store the RAM contents before hibernation?

Hibernation allows you to power down a computer in a saved state. When hibernation is activated, your system takes a snapshot of your current session, saves it in a “hiberfil.sys” file on your hard drive and then powers down completely. When the computer is awakened, it reads the “hiberfil.sys” file and then starts up in the same state it was in prior to entering hibernation. The whole process takes a fraction of the time that it typically takes a computer to cold boot.

Can we modify that stored file to break some security rules of Windows?

Theorically yes.

If you have physical access to the machine you could remove the drive, mount in another computer, make changes, replace the drive, and restart the machine.

You cannot make changes without using a second computer or (as pointed out by Daniel B) using other boot managers/media on the original computer.

I don't know whether the hiberfil.sys file is checked for tampering before resuming from hibernation.

In addition see below for possible vulnerability regarding encryption keys.

Although convenient and reliable, a hibernating operating system can be exposed to some serious security flaws, especially if you are using software encryption applications like Bitlocker or TrueCrypt to secure private data stored on your local hard drive.

As stated previously, prior to entering hibernation mode the computer’s saved state information is written to a “hiberfil.sys” file and stored on your hard drive’s root directory. This “hiberfil.sys” file is basically a snapshot of your system’s RAM. If your encryption software is running when your system is put into Hibernation your encrypted data could be at risk.

From the article “Windows Hibernation and hiberfil.sys” published on the nti-Forensics website:

The Windows hiberfil.sys can also be an issue when using encryption software… …If a Windows system is placed into hibernation mode without unmounting encrypted containers or volumes then the encryption keys used to access these containers could be left in RAM in plain-text. RAM will then be saved to the hard drive in the hiberfil.sys. This means that you will be leaving the keys (passwords) to all of your private containers and volumes free for the finding.

So if your encrypted volume was left mounted when you put your computer into hibernation mode, the entire contents of your encrypted partition could be exposed if your hard drive is compromised and the attacker is able to extract the encryption keys from the “hiberfil.sys” file.

First, let me say that you're not alone. This is almost certainly the most common question in the "Windows" + "Memory" areas here. It may well be in the top ten across all of SuperUser. And I blame Microsoft for not explaining things well, for not using good, consistent names for metrics across multiple displays, and not providing an easy-to-find-and-follow answer to this question, despite its "popularity".

In short, your confusion is understandable, even expected. It's not your fault.

The quick answer

If you're seeing "out of memory", "low on memory", etc., pop-ups from Windows, you really, really, really need to have a pagefile. Or increase the size of the one you already have.

(Or add more RAM, but that's not as easy. Or try to run fewer/smaller programs at one time, but nobody wants to do that.)

I have disabled it because I have a 250GB SSD.

Sorry to be blunt, but this doesn't make any sense. If you'd said "...because I have 64 GB of RAM", that would make some sense. Maybe. But having an SSD doesn't mean you don't need a pagefile.

Even having 64 GB of RAM doesn't guarantee you don't need a pagefile!

That error message, in fact, is telling you that you absolutely do need a pagefile. (Or more RAM... or you need to run less stuff and/or smaller stuff at one time.)

Yes, I know. You don't want to put a pagefile on your SSD. I'll address that at the end.

When it says "out of memory", it doesn't mean what you think it means

That error message is triggered by running out of something called "Commit Limit", not RAM. "Committed", or rather "private committed" to give it its full name, is a type of virtual memory in Windows. You probably know that the contents of "virtual memory" are to be found either in RAM or, if there isn't room for all of it, some of it is kept on disk (or SSD). For "private committed virtual memory", the place it's kept on disk is the pagefile. If you have one.

(There is also "mapped" virtual memory, which uses other files for paging instead of the pagefile, and there is nonpageable virtual memory, which has to stay in RAM at all times. Nonpageable v.m. contributes to "commit charge" so if you have too much of it it can contribute to the "out of memory" error message. Mapped memory does not so contribute, so I won't discuss it much here.)

What if you don't have a pagefile? Your programs can still create private committed virtual memory. But then all committed virtual memory that's been written to since it was first allocated has to stay in RAM at all times... until it's released (usually by ending the process that created it)... Because there's no place else for Windows to keep it.

The "commit limit" - that is, how much committed, written-to-at-least-once virtual memory that you can have - is therefore simply the size of your RAM plus the current size of your pagefile. (If you have pagefile expansion enabled, the commit limit enlarges when the pagefile does.)

If you will look at Task Manager, Performance tab in Windows 7, you will see an indication that looks like this:

Commit (MB) 893 / 4095

This says my commit charge is 893 MB, and my commit limit is 4095 MB, i.e. 4 GB. (This is from a virtual machine running Windows 7. It has 2 GB "RAM" and a 2 GB pagefile - so the commit limit is 4 GB.)

The "out of memory" error message appears when a program tries to allocate committed virtual memory, and the request cannot be granted because the system's "commit charge" is already at or near the "commit limit" - near enough that the request, if granted, would take commit charge over the limit.

Note that you see this message only after the request to "commit" has already been attempted and failed. So when you look at Task Manager, the reason for the problem might not be apparent.

Suppose you had 1 GB of commit limit left, and something tries to allocate 1.5 GB in one call. (This is uncommon, but it can happen.) The memory manager will reject the request and you'll see the popup. But then when you look at Task Manager you will still see your commit charge where it was before, with 1 GB still unused! Confusing. There is nothing in Task Manager, Resource Monitor, or even Performance Monitor that tells you how much was requested, either.

(The Process Monitor tool from sysinternals.com might help here.)

That error message really should say something like "Attempt to commit (size of request) would exceed commit limit", and although this would require people to look up what "commit limit" meant, it would be far more useful. Ah well, this is far from the only not-as-helpful-as-it-could be error message that's in Windows - or in any other OS I've ever used. (They could at least put more details in the system event log!)

Note that whenever you talk about "memory" on Windows, you should always qualify it - are you talking about "virtual memory" or "physical memory"? A lot of people say "memory" when they could mean either. And a lot of people say "RAM" when they're really talking about virtual memory. This only adds to everyone's confusion.

As I said earlier, the stuff that's counted in commit charge is one type of virtual memory. The commit limit is the maximum amount of that type of virtual memory that you can have. You can make the commit limit larger by adding more RAM and/or by increasing your pagefile size.

But I have plenty of RAM!

I cannot understand why I need to use Virtual Memory with 12GB of RAM.

That's a completely understandable question. And a very common one. And again I blame Microsoft for not explaining things better.

Briefly: You need a pagefile because your workload is trying to allocate more "committed virtual address space" than you have RAM.

First, terminology: Windows is always using virtual memory, whether or not you have a pagefile. Getting rid of the pagefile simply precludes paging to disk for committed virtual memory; the committed v.m. still exists and is still virtual, in every way except for being pageable to disk.

But another major type of virtual memory, the sort called "mapped memory", continues to page. Just not to the pagefile.

So what you're really asking is, why are you running out of your commit limit if you have 12 GB of RAM?

Well, that would be because however much you're already using, plus the size of an amount that some program is asking for, would exceed your commit limit.

You can see that message even if you have plenty of RAM "available", as reported in Task Manager. Conversely you might not see the message - i.e. a commit attempt can succeed - even if you have little "available" RAM. Because it's not complaining about available RAM. It's complaining about lack of commit limit.

Your program might be trying to allocate huge amounts of committed virtual memory. Or you might have something else running that's using up the commit.

Now here's a funny thing: When a process allocates committed memory, that doesn't actually use RAM equal to the committed amount. Because it's virtual, remember? In fact it takes very little RAM to just commit virtual memory, even without a pagefile. It's just saying "I ''might'' want to use up to ''this'' much committed virtual memory. Windows, can you promise ("commit") me that that much will be accessible, even if I use it all?"

Only until the program actually writes to that committed memory - by accessing it and so incurring page faults - does RAM actually come off of the "available" counter and get added to "in use". This happens on a page-by-page basis. If you write to 10 pages (4K each) within the committed region, that'll use 10 pages (40KB) of RAM.

(It would happen if you read from it, too, but it makes very little sense to read from newly-allocated virtual memory before you write to it.)

Very often the program will never actually access all of the private v.m. it has committed, in which case the RAM used will not equal the amount committed. (And on a system with a pagefile, some of the "committed" stuff might be moved out to the pagefile, to make more room in RAM for other things... further reducing the RAM used by the committed region.)

But Windows has no way of knowing how much of the committed region will be used; when making the allocation, it has no choice but to assume that I ''might'' actually use all of it. This means that 1 GB total of actual storage would be needed to keep it all (possibly some of it in the pagefile and the rest in RAM).

So it can't grant that request unless all of the current "commit" allocations together, plus the new one, would be less than the commit limit.

If it granted the request anyway, then there would be a risk of actually running out of RAM, i.e. being unable to resolve a pagefault because no RAM was available. That's considered a very serious problem. It's much easier, both on the OS and on application programmers, to enforce the limit when the program tries to commit the virtual memory.

For more info (as if this wasn't long enough already)

For more on this, explained in somewhat different ways, please see two of my other answers: here (longer) uses a "loans from the bank" analogy that some people have found effective. this one (much longer) has a more formal explanation of what's happening inside the OS. Often having the same concept presented in several different ways will help you get past a sticking point.

About the pagefile vs. the SSD

This is a side issue, so I moved it down here...

all web pages about SSD explicit tell to disable Virtual Memory to avoid disk wear

Sorry, but no, not all say that, and those that do are just wrong. Modern SSDs will handle petabytes of writes before starting to show problems. And from Support and Q&A for Solid-State Drives (msdn):

Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,

Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.

Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.

In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

Here's one more surprising fact: Even though you may need a pagefile to allow the system to grant these requests, there may be very little, maybe even nothing, actually written to the pagefile! Again, this is because there's usually quite a difference between how much virtual memory is committed and how much actually gets used. By used we mean "written to, and pages of RAM assigned accordingly". Only private committed v.m. that's actually written to will ever go in the pagefile. Most modern systems (like yours, with 12 GB RAM) don't write and read the pagefile very much. Nevertheless, the pagefile is often necessary to allow the virtual allocations to succeed. And maybe that will set your mind at ease about putting it on your SSD.