[Feature Request] Support for Secure Boot compatible imaging workflow

[pudquick]

Apple has made changes to asr's functionality and the workflow for restoring APFS images to Secure Boot devices and preserving trust / preventing Startup Security Utility from displaying dialogs that you need to connect to the Internet is slightly different than what Restor currently does for APFS.

Right now Restor deletes the APFS container partition and then re-creates it and then targets the newly created container as the restore destination.

In practice for us, this seems to cause problems with the iMac Pro (the only Secure Boot device model Apple currently makes). Devices that are imaged in this way seem to have problems with the new "encrypted at rest" capabilities and cause errors when attempting to enable FileVault2.

We noticed, however, that the text of the asr manpage changed under the section "RESTORING WITH APFS FILESYSTEMS" and a new section appeared regarding restoring volumes using erase.

An example of using asr directly with the new workflow is presented here:

iMac Pro, when Target Disk Mode attached to another Mac, the mounted disks show as follows:

/dev/disk2 (external):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         1.0 TB     disk2
   1:                        EFI EFI                     314.6 MB   disk2s1
   2:                 Apple_APFS Container disk3         1.0 TB     disk2s2

/dev/disk3 (external, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0: UUID-SHOWS-UP-HERE                                +1.0 TB     disk3

In this case, the APFS container can be referenced as both disk2s2 or disk3.

The command for restore is now just simply:

sudo asr restore --source os_image.apfs.dmg --target /dev/disk2s2 --erase --noverify --noprompt

Note that we do not remove and re-create the container.

When used with this more recent build of macOS (on the host machine running Restore), the output looks like as follows:

Validating target...done
    Validating source...done
    Retrieving scan information...done
    Validating sizes...nx_kernel_mount:1359: : checkpoint search: largest xid 130, best xid 130 @ 3
done
    Restoring  ....10....20....30....40....50....60....70....80....90....100
    Inverting target volume...done
    Remounting target volume...done
Personalization over TDM succeeded

Note the last line - which is key. Personalization has occurred. This requires that the host machine running Restor has access to Apple's services over the internet at restoration time and that the OS that you're installing to the Secure Boot device is compatible/bootable for that device (otherwise personalization will fail).

This results in a device which, at power on, with Full mode security (the default) enabled for Secure Boot, it will successfully boot the OS without triggering Startup Security Utility. Additionally, the volume is marked "encrypted at rest", the first user logging in gets a SecureToken, and you are able to properly enable FileVault2.

For this feature to work successfully, it may require detecting the OS that Restor.app is running on.

Additionally, I might suggest providing a preference for enabling an additional flag --no-personalization, which isn't documented, but it prevents the last step if that's necessary for some reason.

[pudquick]

The iMac Pro macOS build 10.13.3 (17D2047) has the text in question in the manpage which indicates support for this behavior: "Volume Restore With Erase" (under the "RESTORING WITH APFS FILESYSTEMS") section.

OS builds with this section present in the manpage seem to be an indicator for this mode of operation and successful personalization during asr restores.

May need to do some research and gate it to these builds + whatever future OS version un-forks and unifies all this behavior.

[pudquick]

Additionally - this workflow is compatible with re-conditioning devices that were deployed that have a single APFS OS volume, even if FileVault2 encrypted.

When tested against devices in this state, asr was able to handle deleting the FV2 encrypted volumes and restoring without problem automatically.

[tburgin]

Restor 1.5 running on 10.3.4 (17E199), in my testing, successfully restores an 10.13.4 (17E199) APFS image to an iMacPro. I have not tried using an 10.13.3 (17D2047) image. If anyone has one I can test it out.

[ghost]

@tburgin
I get this error when using Restor 1.7 on a T2 MBP to image using 10.13.6-17G65.apfs

Restor gives this error at the end during "inverting" Here is the log

2018-08-29 09:27:44.424 com.google.corp.restord[741:85000] Client disconnected, exiting.
2018-08-29 10:40:16.493 com.google.corp.restord[784:33347] Client connected.
2018-08-29 10:40:26.377 com.google.corp.restord[784:33350] <ImageSessionServer: 0x7fa98ed05300> New imaging client: s: 'sales-sep2018v1-10.13.6-17G65.apfs', d: /dev/disk2s2
2018-08-29 10:43:13.893 com.google.corp.restord[784:35091] <ImageSessionServer: 0x7fa98ed05300> ASR unknown line: Personalization failed: Error Domain=OSPErrorDomain Code=103 "The given secure boot bundle is invalid." UserInfo={NSLocalizedDescription=The given secure boot bundle is invalid.}
2018-08-29 10:43:14.188 com.google.corp.restord[784:33350] <ImageSessionServer: 0x7fa98ed05300> ASR unknown line: asr: Couldn't personalize volume /Volumes/Macintosh HD 1
2018-08-29 10:43:14.300 com.google.corp.restord[784:33347] <ImageSessionServer: 0x7fa98ed05300> ASR exit code: 1
2018-08-29 10:44:54.381 com.google.corp.restord[784:35868] Client disconnected, exiting.

I have you encountered this before? Thank you for your hard work.

[tburgin]

17G65 is not compatible with the 2018 MBPs. I think you are looking for: 17G2112.

[ghost]

ha! Thanks for the heads up. You ever played around with 17G2208?

[ghost]

I used installinstallmacos to pull down build 17G2208; the current T2 2018 built before the supplemental 2 update(17G2037). Then made it compatible with autoDMG and bingo! No barks from restor or imagr, no errors. @tburgin Thanks again!

[jake-stripe]

Chiming in just for the sake of further confirmation— I pulled down 17G2208 with installinstallmacos.py; no issues imaging 2016-2018 MBPs on v1.8 of Restor.