Decrypting from the Mavericks 10.9.4 Recovery HD partition - Possible Diskutil Bug

Originator:rtrouton
Number:rdar://17985943 Date Originated:8-11-2014
Status:Closed Resolved:
Product:OS X Product Version:10.9.4 (13E28)
Classification:Security Reproducible:Always
 
Summary:

The diskutil tool found in the 10.9.4 Recovery HD partition appears to have a bug that prevents the CoreStorage volume from being properly removed when the following command is run on an unlocked FileVault 2-encrypted drive:

diskutil corestorage revert UUID_here


Steps to Reproduce:

1. Booting from a Mavericks Recovery HD partition (all testing done with a 10.9.4 Recovery HD partition.)

2. Unlocking the encrypted drive (either using Disk Utility or diskutil corestorage -revert

2. Decrypting either of the the following methods:

Using Disk Utility to decrypt the FileVault 2-encrypted boot drive. General method described here - http://derflounder.wordpress.com/2011/11/23/using-disk-utility-to-unlock-or-decrypt-your-filevault-2-encrypted-boot-drive/

Running "diskutil corestorage -revert" from the Terminal. General method described here - http://derflounder.wordpress.com/2014/04/27/unlocking-or-decrypting-a-filevault-2-encrypted-fusion-drive-from-the-command-line/

3. Letting the drive get to "Conversion Progress: 100%" while booted from the Recovery HD partition. "Conversion Progress" status was displayed via "diskutil corestorage list"

4. Rebooting back to the main boot drive once "Conversion Progress:" has reached 100%.


The end result is a locked CoreStorage volume that will not allow the boot drive to boot normally. The drive will also not unlock or mount when accessed from a Recovery HD partition. 

Expected Results:

When "Conversion Progress:" in "diskutil corestorage list" had reached 100%, the expected outcome was that the CoreStorage volume would be removed and the drive be converted back to a normal HFS+ drive.


Actual Results:

When "Conversion Progress:" in "diskutil corestorage list" had reached 100%, the CoreStorage volume was not removed. On booting from the Recovery HD partition to the now-decrypted drive, the Mac booted to a prohibited sign. This symbol at boot means the system has found a bootable installation of Mac OS X on the system, but there is something wrong with it.

Regression:

In my testing of this problem, I identified two workarounds for this issue:

A. Reboot from the Recovery HD partition before the drive fully decrypts

It appears that the issue is specific to completely finishing decryption while booted from a Mavericks Recovery HD partition. However, if you start decryption on a drive, then reboot, decryption will continue after the reboot. 

To take advantage of this behavior, I tested and verified that if you start decryption while booted from the Recovery HD partition, then reboot from the Recovery HD partition to a drive running a full version of OS X 10.9.x, decryption finishes normally.



B. Decrypt using the command line and run "diskutil corestorage revert" twice 


In my testing, I verified that running diskutil corestorage revert will decrypt the drive. Running "diskutil corestorage revert" a second time directly after that first diskutil corestorage revert command will result in the the CoreStorage volume being removed and converting the drive back to a normal HFS+ drive. On reboot, the now-decrypted drive will boot normally.

Notes:

In my testing, I did find it was possible to decrypt the drive via Disk Utility or the command line when it was attached as an external drive (via Target Disk Mode or other means) to a Mac that was booted to a full version of OS X 10.9.x. Once decrypted, I verified that the CoreStorage volume was removed. Once I had verified that, I further verified that I could now boot normally from the previously non-bootable hard drive.

One drawback to decrypting while attached to a regular 10.9.x boot drive is you would not be able to use an Institutional Recovery Key (IRK). Using that kind of recovery key for unlocking or decryption only works when booted from a Recovery HD partition or Internet Recovery. Since that's precisely where our problem exists, I investigated further to see if there were alternate workarounds for this problem (see Regression section for information on workarounds.)

Comments

Response from Apple on 14-Oct-2014 04:15 PM

Thank you for filing this bug report.

We are closing this report since our engineers have determined that the issue is not going to be addressed.

We have no plans to start the decryption while in the recover volume.

If you have questions regarding the resolution of this issue, please update your bug report with them.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

Again, thank you for taking the time to submit bugs. We sincerely appreciate your input.

By rtrouton at Oct. 20, 2014, 4:02 p.m. (reply...)

Update posted on 04-Oct-2014 04:01 PM

I've updated to GM 1 build 14A379a and verified that Recovery HD is running 10.10, build 14A379a. I'm seeing the same behavior that I saw with DP 5, DP 7 and DP 8, where decryption now does not begin until I have booted back to the main boot volume (which is now running GM 1, build 14A379a). I have also verified that the following previously suggested changes have not been included in GM 1, build 14A379a.

  1. Allow the diskutil tool on a regular Yosemite boot volume to be able to use a recovery keychain to unlock / decrypt a FileVault 2-encrypted volume.

  2. Make the decryption message displayed by diskutil in Recovery HD more explicit that only the initiation of decryption has begun and that decryption will continue and complete once booted to a regular Yosemite boot volume.

By rtrouton at Oct. 20, 2014, 4:01 p.m. (reply...)

Update posted on 05-Sep-2014 05:46 PM

Engineering has overlooked the major reason why people boot to the recovery partition to unlock/decrypt - the only place that you can unlock or initiate decryption when using an institutional recovery key (aka a recovery keychain) is when you're booted from Recovery HD or Internet Recovery. Trying to use a recovery keychain while booted from a regular boot volume produces a diskutil error.

With this in mind, there are two things that would resolve this bug satisfactorily if done together:

  1. Allow the diskutil tool on a regular Yosemite boot volume to be able to use a recovery keychain to unlock / decrypt a FileVault 2-encrypted volume.

  2. Make the decryption message displayed by diskutil in Recovery HD more explicit that only the initiation of decryption has begun and that decryption will continue and complete once booted to a regular Yosemite boot volume.

By rtrouton at Oct. 20, 2014, 4 p.m. (reply...)

Response from Apple on 05-Sep-2014 12:05 PM

Engineering has provided the following information:

The recovery partition doesn't usually get updated on software updates. An erase install is required to update it.

In Yosemite, FDE conversion will not make any progress when booted into the recovery partition. Even in Mavericks, if you rebooted back into the OS partition and then rebooted back again into the recovery partition the conversion would not make progress. Also in Mavericks, decryption was never able complete. The reason for this behavior is that the daemon, corestoraged, does not run in recovery environment.

The main reason for allowing disabling FDE from the recovery partition is for users that have a keyboard that does not work with the EFI loginwindow. Given that, I think the main concern is that disabling FDE from recovery partition on Mavericks could leave the machine in a state where the OS partition did not boot (if you let the conversion run until it got stuck). That issue should hopefully no longer occur in Yosemite.

Please let us know if that resolves the issue for you by updating your bug report.

By rtrouton at Oct. 20, 2014, 4 p.m. (reply...)

Update posted on 04-Sep-2014 10:35 AM

My previous tests have been in VMware Fusion VMs, so to help make sure that I wasn't seeing an odd virtualization issue, I repeated it on a 13 inch Retina running 10.10 DP7. I was able to replicate my previous results.

I also tried rebooting, where I rebooted back to Recovery HD. The only change I saw was that "Conversion Progress" changed from "-none-" to "Paused". Booting back to the regular 10.10 boot disk allowed decryption to proceed. 'MacBook Pro.spx', 'Terminal Saved Output1.txt', 'Terminal Saved Output2.txt' and 'Terminal Saved Output3.txt' were successfully uploaded.

By rtrouton at Oct. 20, 2014, 3:59 p.m. (reply...)

Update posted on 03-Sep-2014 07:52 PM

I've updated to DP 7 and verified that Recovery HD is running 10.10, build 14A343g. I'm seeing the same behavior that I saw with DP 5, where decryption now does not begin until I have booted back to the main boot volume (which is now running DP 7, build 14A343f). I'm attaching a copy of the Terminal output from Recovery HD. 'Terminal Saved Output.txt' was successfully uploaded.

By rtrouton at Oct. 20, 2014, 3:58 p.m. (reply...)

Update posted on 20-Aug-2014 01:42 PM

I've tested booting from the OS X Yosemite DP5 Recovery HD partition and the problem is different, but I cannot verify that the reported behavior is actually fixed. Decryption now does not begin until I have booted back to the main boot volume (which is now running DP 6, build 14A329f).

Is there any way to build a Recovery HD partition that is running 14A329f?

By rtrouton at Oct. 20, 2014, 3:58 p.m. (reply...)

I've added more details and screenshots at the blog post available here:

http://derflounder.wordpress.com/2014/08/12/problems-decrypting-filevault-2-encrypted-drives-while-booted-from-mavericks-recovery-hd/

By rtrouton at Aug. 12, 2014, 3:09 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!