[Feature Request] Support for Secure Boot compatible imaging workflow #16
Description
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.