Hibernate and encrypted HDD

Discussion in 'macOS' started by joe4444, Feb 19, 2015.

  1. joe4444 macrumors newbie

    Feb 14, 2015
    When entering hibernation, does OS X explicitly lock an encrypted HDD? I'm not talking about FileVault 2 on the system volume. My second HDD is encrypted.

    Looking at the system log, I can see when I boot it explicitly mounts both the system volume and my second HDD (of course). However, I do not see anything in the log during shutdown that looks like it explicitly unmounts the drives, but that may just be me not searching for the correct term.

    Unexpectedly, I do not see any explicit mount notes in the system log when waking from hibernation. I thought OS X would unmount drives when going into hibernation. That does not appear to be the case, or the re-mounting event is not logged, which seems unlikely.

    So, if drives are not unmounted when going into hibernation, is there some sort of explicit "lock" happening for an encrypted (non-system) volume?
  2. maflynn Moderator


    Staff Member

    May 3, 2009
    They're not ejected AFAIK, what purpose would a lock do?

    If the drive is encrypted, then any decryption occurs on the fly, it doesn't matter about the state of the computer.

    I'm not sure I fully understand your point about being locked.
  3. mfram macrumors 65816

    Jan 23, 2010
    San Diego, CA USA
    As pointed out by the previous poster, the data physically on encrypted drives is always encrypted. "Unmounting" a drive just tells the operating system to flush all data to disk that hasn't been written yet and to remove the key from RAM. But there is no 'lock'.

    There is a software layer running in the operating system that decrypts the data as it is read off the drive and encrypts the data before is it written on the drive. The only issue is whether that layer is active and has the key for encryption in RAM.

    During hibernation (RAM is powered down, memory saved to disk), I believe the key to the system volume is not kept. I say that because on my machine I have to type my password in to unlock the encrypted system volume when coming out of hibernation. I don't know about secondary disks. This is on Yosemite.
  4. joe4444 thread starter macrumors newbie

    Feb 14, 2015
    Okay, I understand what you mean by removing the decryption key from memory before hibernation. However, I assumed that if the system is powering down for hibernation, then the disks would be unmounted before losing power. Regardless, here is what I'm trying to accomplish (if it is even possible):

    OS X is installed to my SSD. I also have a secondary HDD in the MacBook's optical bay. The SSD is encrypted with FileVault 2 (full drive encryption), and the HDD is encrypted "manually" through Disk Utility. Upon waking from hibernation, to access the SSD the system needs the key so it prompts for my password. Then once it is able to decrypt the contents of the SSD, the system can read my hibernation file (sleepimage) and restore everything as usual. Importantly, included in "everything as usual" is automatically unlocking the encrypted HDD (because the password is saved to my Keychain). So it's seamless as intended.

    However, if I move sleepimage to the HDD, this process fails. I'm not sure exactly where/when, but when I wake from hibernation the system prompts for my password as usual. Immediately after I press Return it reboots. It seems like the system does not attempt to access Keychain to unlock any other partitions before it attempts to read sleepimage. This may be due to the fact that sleepimage must be read before anything else can be executed. I can't find documentation on the wake-from-hibernation sequence. Although there is plenty of easy to find information about details of the boot sequence, I'm stumped on this one.

    It would be great if I could offload sleepimage to the HDD, saving a lot of big writes to the SSD every day. I'd still be able to use the convenience of simply closing the MacBook lid while maintaining the security of my encrypted data.

Share This Page