When will we configure Hibernate 25? Is it valid for M series MacBooks?
Is Hibernate 25 called deep sleep mode?
So, let me start by quoting the man page for pmset:
"hibernatemode = 3 by default on portables. The system will store a copy of memory to persistent storage (the disk), and will power memory during sleep. The system will wake from memory, unless a power loss forces it to restore from hibernate image."
...
"hibernatemode = 25 is only settable via pmset. The system will store a copy of memory to persistent storage (the disk), and will remove power to memory. The system will restore from disk image. If you want "hibernation" - slower sleeps, slower wakes, and better battery life, you should use this setting."
The thing to understand here is that the difference between those two ISN'T about how either mode “prepares" for sleep. Both of them do exactly the same thing— that is, they flush all memory to disk, ensuring that power loss won't lose any data. The difference is that having done that flush, Hibernate 25 then cuts power to memory, effectively simulating EXACTLY what happens in Hibernate 3 when the machine loses all power. Indeed, its original role was exactly that— that is, simplifying the process of testing how "full" power loss restoration works by removing the need to physically cut power to test that case.
Similarly, hibernate 3 is the default for exactly the reasons listed under hibernate 25. That is, if power ISN'T lost, hibernate 3 is faster to wake since it simply restores the machine directly from memory.
As a side note, I will say that I think that the "slower sleeps" comment is slightly misleading. EXACTLY what happens when a machine "goes to sleep" isn't really formally documented, but you can clearly see from our own logging that we don't IMMEDIATELY stop the normal execution flow and the machine can stay fairly active for a significant amount of time after it's visibly "gone to sleep". Similarly, particularly when plenty of battery is available, I believe we may delay writing the hibernate file for a significant period of time, as the power cost of the hibernate file is significant enough and short sleeps common enough that deferring it for "awhile" has power benefits.
I haven't played with it in a while, but I believe Hibernate 25 basically disables all of that, writing out the hibernate file "immediately". Again, this mode was originally created as a testing/development aid, where you wouldn't want to worry about whether not you'd waited "long enough" for the hibernate file to wake.
What are the settings I need to do on Mac, to make my Mac go into deep sleep?
What do you mean "deep sleep"? What are you actually trying to test/understand?
Keep in mind that, under real-world conditions, the complicating factor here isn't just system settings, it's the interactions between:
-
The settings the user has configured.
-
System-level features like dark wake (which periodically wakes the Mac to perform maintenance tasks).
-
App and other “user-level" features/functions preventing sleep.
-
External hardware or other factors disrupting sleep.
All these factors mean that there can be a BIG difference between how "macOS works" (meaning, what does the base system do without any other configuration) and how "this Mac works" (meaning, a specific device and its full configuration). In practical terms, it doesn't really matter how the system is configured if a USB mouse (or some other hardware) attached to it keeps waking the Mac app.
When awakening from deep sleep, what would be macOS system behaviour?
In terms of security authorization, this depends on how the machine is configured. One of the "Lock Screen" settings is "Require password after screensaver begins or display is turned off" and the timing options range from “Immediately "Never". I'd expect the first ("always") and last ("never") to behave exactly how you'd expect, but I also wouldn't be surprised if an edge case like this:
- Configure the machine for "8 hours".
- Put the machine to sleep and wait 2 hours (to ensure the hibernate file is written).
- Cut all power to the machine (creating/simulating full battery drain).
- Wait 2 hours.
- Restore power and wake from sleep.
The machine has only been asleep for 4 hours so, per the machine’s configuration, it should NOT ask for the password. However, I wouldn't be at all surprised if it, since asking for the password is the safe option.
Finally, there's one other complication that will affect this:
If we have a custom SFAuthorization plug-in at system.login.screensaver, what would be the behaviour with deep sleep?
You can find an in-depth run-through of how hibernation works in the xnu doc here. However, the general flow of the process is:
-
The machine powers on into the preboot system.
-
The preboot system detects that the machine has hibernated and validates the hibernate data.
-
The preboot system reads the preboot data directly from disk and into memory* at exactly the same location, then turns execution over to the kernel code it just loaded.
-
The restored kernel is then responsible for returning the machine to "normal" operation by pulling swapped data out of the VM system.
*As an aside on that point, one subtle "trick" here is that the system DOESN'T actually need to write "all of memory" to the hibernate file. It can actually flush as much as possible to disk through the standard VM system, so what's actually written to disk in the hibernate file is the part of the kernel necessary to kick off the process of hibernate restoration and wired memory.
In that standard flow, whether or not authentication is required depends entirely on the system-level settings above, as authentication occurs "after" the original system is "running". However, there is one other setting involved which is this (from pmset):
destroyfvkeyonstandby - Destroy File Vault Key when going to standby mode. By default, File Vault keys are retained even when the system goes to standby. If the keys are destroyed, the user will be prompted to enter the password while coming out of standby mode.(value: 1 - Destroy, 0 - Retain)
With this setting, the preboot system needs to authenticate so that it can restore the File Vault keys. I'm not sure how that will interact with system.login.screensaver, but it's possible the preboot authentication might end up bypassing the screensaver unlock through the same general mechanism that cold boot login uses.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
