MBA fails to wake (Platform Failure) after entering Low Power Sleep state

Update: removing the user causes the problem to return, adding the user again eliminates the problem once more.

My noble hero! This solution works for me as well.

I had to create a new user some time back. I also noticed the probelm had dissapeared but I didn't connect the dots as I had done all sorts of other things trying to remedy the bug. So I can't be sure what fixed it. But there is a chance that "your fix" worked for me as well. Still, there is a problem with the delay - possibly during which decryption takes place - where the user is left not knowing what goes on. Would be nice to have some sort of wait symbol appear immediately when waking up the MB Air.

vonkas wrote:

Would be nice to have some sort of wait symbol appear immediately when waking up the MB Air.

I agree completely. I'm terrified every time I wake the air from sleep that it won't work. Luckily it seems to work every time so far /knock on wood/

Works for me too, but indeed breaks again when removing the user. Has anyone tested if it works when removing the current user?

I never had this problem, since I always had two users (one to decrypt the disk and one with a shorter password to unlock the screen, who was not able to unlock the disk)

However, there is a strange problem which might be related:

If I do sudo pmset -a hibernatemode 25 all data from Ram will be written to disk and the Ram will be erased upon standby. But I can still wake up and ONLY enter the weak user-password which is not able to decrypt the disk and still log in.

How is this possible? Where is the key saved, if the Ram is cleared? Does it get written to disk in plain-text?

Interesting. Do you have standby set to 0 or 1 ?

If set to 1, what is your standbydelay?

How can you disable decryption-ability for a user?

You can not. But all users that were created before you activated FV2, can not decrypt unless you explicitely enable them. So the only possibility to lock out a user from FV2 decryption is to decrypt the disk and reencrypt it again and not activate this user.

@cmeid:

I didn't change anything there. How do I find this out?

% pmset -g | grep standby

standbydelay 4200

standby 1

Also, what setting do you have for DestroyFVKeyOnStandby ? Is that 0 or 1 ?

The reason I ask, is that I see the following in the man page:

STANDBY ARGUMENTS

standby causes kernel power management to automatically hibernate a machine after it has slept for a specified time period. This saves power while asleep. This setting defaults to ON for supported hardware. The setting

standby will be visible in pmset -g if the feature is supported on this machine.

standby only works if hibernation is turned on to hibernatemode 3 or 25.

standbydelay specifies the delay, in seconds, before writing the hibernation image to disk and powering off memory for Standby.

So, clearly standby works with hibernatemode 25. I wonder whether setting standby to 0 would cause the behavior you are looking for.

Message was edited by: cmeid to add man page info

I have

standbydelay 4200

standby 1

Hibernatemode 0

DestroyFVKeyOnStandby 1 (makes no sense with Hibernatemode 0)

Maybe I explain my original experiment: I activated FV2 and ran the battery down to 1%. Then shut the lid and let it sleep. The next day I opened it and it was dead. I connected the power, waited a minute and opened the lid. It took much longer to wake up compared to when I reopen the lid immediately. This way I could be absolutely sure that the Ram was cleared (loss of power) and that it woke up from disk. But I was still able to log in with my weak user password, that can not be used for decryption.

This means that in a standard configuration the FV2 key will be stored in a permanent location in this situation. If true, this would be a huge security risk. But where is the key stored? Does it get written to disk in plaintext?

So, the way I read the man page, standby still has an effect even though you have hibernatemode 25.

Try setting standby to 0 and see if that helps.

Also, just for clarity, when you say unlock the disk you mean the gray screen right?

So, when you open the lid after hibernation, you are logging in twice, correct? (Once in the gray filevault login screen and again in the window manager lock screen?)

Now, until now you were talking about hibernatemode 25. I assume you took that from pmset when you were on AC?

Check again with pmset -b -g (this will give you the settings for when you're on battery) to make sure you're really on hibernatemode 25. If you want the behavior to work when you're on AC as well, then you need to set it that way. Hibernatemode 0 turns off disk hibernation, and always stands by to RAM.

I think there is a misunderstanding here. At the moment I am using hibernatemode 0, because I don't want my key to be written to the disk for everyone to read (I assume it's the disk where it gets written to as I have no other explanation where it could be read from on wake up)

I USED to use hibernatemode 25 (or 3), but this was just to expose the security flaw. I'm not using this anymore.

When I say "unlock the disk", I mean the gray screen, that comes first if you do a fresh boot.

If I wake up from sleep (hibernatemode 25 DestroyFVKeyOnStandby 0), I ONLY enter one password on the regular screen-unlock, not the gray screen. The password I enter there is my weak user password that can not decrypt the disk.

I would expect this behaviour only from hibernatemode 0 (as I have right now), but not from 25, because there should be no possibility to get around entering you decryption password. But since there is, I conclude that the decryption key must be stored in a permanent memory and that is a very severe securitry risk.

Ok, gotcha.

If I wake up from sleep (hibernatemode 25), I ONLY enter one password on the regular screen-unlock, not the gray screen. The password I enter there is my weak user password that can not decrypt the disk.

This is why I was wondering about setting standby to 0. If you are only getting the regular screen unlock, then the machine wasn't fully hibernating, it was just in standby. If it's hibernating (and power to RAM is off) you'll get the gray screen again.

Try setting standby to 0 to see if it hibernates all the way immediately. I /think/ what's happening is that the image is being written to disk immediately, but RAM is not powered off until 4200 seconds have passed. Alternatively, you could turn standbydelay to 10 with hibernatemode 3. This I have tested and works at least on my box.

The man page is contradictory - hibernatemode 25 claims that RAM will be powered off immediately, but standby claims to have an effect in both hibernate mode 3 and mode 25. Thus my curiousity whether turning standby off will have the effect you want.

To bring some sense into this, I'm now trying every possible combination and see what happens. (MBA Mid 11, 10.7.2) I have different passwords for user login and disk decryption.

Standby is always 1, standbydelay always 20, all options are set via "pmset -a" so they apply for battery and AC.

sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 3 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock

On battery, reopening the lid after 30 s: asks for gray decryption password, then regular screen unlock

On AC, reopening the lid after 15 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock --> this is unexpected, maybe ram is not cleared on AC?

sudo pmset -a destroyfvkeyonhibernate 0 hibernatemode 3 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock

On battery, reopening the lid after 30 s: regular screen unlock -> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

On AC, reopening the lid after 15 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock --> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 0 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock

On battery, reopening the lid after 30 s: regular screen unlock

On AC, reopening the lid after 15 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock

sudo pmset -a destroyfvkeyonhibernate 0 hibernatemode 0 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock

On battery, reopening the lid after 30 s: regular screen unlock

On AC, reopening the lid after 15 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock

sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 25 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: asks for gray decryption password, then regular screen unlock

On battery, reopening the lid after 30 s: asks for gray decryption password, then regular screen unlock

On AC, reopening the lid after 15 s: asks for gray decryption password, then regular screen unlock

On AC, reopening the lid after 30 s: asks for gray decryption password, then regular screen unlock

sudo pmset -a destroyfvkeyonhibernate 0 hibernatemode 25 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock -> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

On battery, reopening the lid after 30 s: regular screen unlock -> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

On AC, reopening the lid after 15 s: regular screen unlock -> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

On AC, reopening the lid after 30 s: regular screen unlock -> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

I've marked all lines italic that are not as they are supposed to be according to the specification of the hibernationmode, and the assumption that the keys must never be written in plaintext into a permanent memory.

Now if we assume that "destroyfvkeysonhibernate 0" really means that the keys get written to a permanent location in plaintext before the system suspends to disk, then all of the bevaviour could be explained. But this would be highly insecure!!!