Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

joe4444

macrumors newbie
Original poster
Feb 14, 2015
11
0
While waiting for my new SSD to arrive in the mail, I've been looking into FileVault 2. I like the idea of knowing that IF my MacBook were stolen, then my data would be as inaccessible as possible. However, I am one of those "always sleep, never shut down" users.

After some reading, I realize that even with FileVault 2, when its asleep my computer would be vulnerable to a cold boot attack. A fairly simple workaround is to configure sleep to go straight to hibernate mode, so then contents of RAM go to the disk, mitigating a cold boot attack. (I'm fine with the slower waking from hibernate, and I'm already used to typing my password when waking from sleep.) I've tested this on my current HDD, and while it's a little slow to wake, I'm okay with it as a more secure alternative to super fast wake from sleep.

However, the problem is that writing contents of RAM to an SSD every time I close the lid (on average at least 10 times/day) will kill the SSD probably within its warranty period because 8GB RAM x 10 hibernations/day = writing 80GB/day x 3 years = over 80TB written...excluding normal use. The Crucial MX100 SSD that I ordered has a 3 year warranty and an endurance rating for 72TB written, so that's really pushing the limit. I don't want to risk a drive failure after only a few years. I'll probably replace the drive after a few years just to be safe, but I'd like to do that on my time, not when forced to do so by a sudden crash.

So, I looked into moving the sleepimage file to the secondary HDD. Of course this is not so simple because FileVault 2 would only encrypt the primary SSD. Thus, manual encryption of the secondary HDD would be needed (otherwise a "cold boot attack" would be even easier with RAM contents firmly planted on the HDD). Many people have noted that if they move their Users folder to an encrypted secondary HDD when using FileVault 2 on their primary SSD, it causes login problems, but these issues can be resolved with a utility like Unlock. I don't care about moving my Users folder, so I would only be putting the hibernation file sleepimage on the encrypted secondary HDD (along with media files like photos, music, and movies that require storage capacity beyond an affordable SSD).

Would a tool such as Unlock also work well for the setup I described?


Note: Yes, I realize that I could try to break my "never shut down" habit, but if there is a workable solution to avoid that, I'd like to make it happen. I already tried to find a solution that shuts down the MacBook when closing the lid (instead of sleep or hibernate), but that seems to be impossible.
 

joe4444

macrumors newbie
Original poster
Feb 14, 2015
11
0
The issue is not limited SSD space. I was concerned about bringing the drive to an early death caused by numerous daily writes of 8GB whenever I hibernate. However, after seeing some stress tests of similar SSDs, which survived 1,000TB to 3,000TB of writes before failing, I think the manufacturer's endurance rating of 72TB is extremely conservative. I also found one Japanese endurance test of the MX100 that I ordered, and through Google translate it appears to show that the MX100 made it to 1,400TB of writes (20X the endurance rating) before it began to fail. With my typical "close the lid and go" habit, it would be 10 years before I'm even approaching 10% of the 1,000TB - 2,000TB write levels that those extreme stress tests showed SSDs can handle. I'll probably just replace the SSD after 3-5 years anyway to be safe because prices will have dropped considerably by then.

That said, I would still like to offload the hibernate sleepimage file from the SSD to a secondary, encrypted HDD just for some added peace of mind, but so far it does not seem to work. Based on my testing with the Unlock tool, it looks like OS X might unmount any non-system partitions before it tries to write RAM to sleepimage because I can track the file's timestamp in two scenarios: when sleepimage is on the encrypted system partition and waking from hibernation works correctly, and when sleepimage is on an encrypted non-system partition and waking from hibernation fails. It seems the system does not even get to write RAM to sleepimage if it is on an encrypted non-system partition before it goes into hibernation, so there is no sleepimage file to access when it tries to wake up again.

Anyone have any ideas that might help to work around this?
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.