Why not just do the usual dd if=/dev/zero of=<disk> bs=1M count=1024 instead of using those weird proprietary tools?
The SSD on these Macs contains system firmware, including the boot picker and recovery mode. Do not wipe the entire top-level block device. They cannot boot from external media, by design.
M1 Macs are not PCs, and you shouldn't blindly apply whatever you think you know from the PC world. Their low-level design is much closer to an embedded device like a Raspberry Pi, minus the SD card slot. https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
It's hard to truly brick these things (you need to wipe NOR flash for that, and even then Apple can fix it without taking them apart, but you can't, because if you wipe NOR flash calibration data is gone and it has to go back through part of the manufacturing test process), but wiping the entire SSD isn't going to help you. If you start messing at that level, you'd better be prepared with another Mac and Apple Configurator 2 to get a proper clean start.
...or like a iPhone.
From that article you linked:
Some PC motherboards implement a similar feature as part of a separate chip, which can flash the UEFI firmware from a USB stick without actually turning on the motherboard normally, but this is only common in higher-end stand alone motherboards.
That might be referring to boot-block recovery, and I haven't seen any with a "separate chip" besides the dual-BIOS type; it's in the same flash (just a normally write-protected part) as the rest of the BIOS. The older ones will look for a flashable ROM image on the first floppy drive, but I'm not surprised if the newer ones will do it with USB instead.
Because modern bios flashback does indeed read from the USB and write to one of the bios chips without even the CPU in place. Obviously there is some form of micro-controller performing this.
On intel, I suppose it would be possible for the management engine CPU in the chipset to do this, but I doubt intel lets motherboard makers run custom code on that, so if it is not some standardized feature, it could not be that. On AMD Ryzen, I'm not aware of a CPU in the chipset.
This all makes me think there is some other microcontroller somewhere that controls the bios flashback process, which would almost certainly be an extra chip.
I believe they just have some sort of extra microcontroller wired to a USB port and the SPI flash chip that stores the BIOS, probably with some sort of switch to ensure the host can't touch the SPI flash when the external microcontroller is attempting to flash it.
It's back to the Apple Store for you.
While architecturally simpler (and probably more secure by allowing the network stack to be removed from the low-level boot infrastructure?), the disadvantage is that you can mess up the 1TR partition. If you do, the only way to recover the machine is to do a DFU restore from another Mac via Apple Configurator. That's not terribly convenient if you don't have another Mac around. (An Apple Store can DFU restore for you, but last I checked Apple Stores are appointment-only due to COVID and it's almost impossible to get an appointment there these days.)
That's up for debate due to certificate expiration issues, isn't it?
The only portable, reliable, robust way to accomplish this is wiping the drive. If the original author had issued a secure erase, they would not have encountered any subsequent difficulties, all of which were due to partially erasing the device.
That's setting the bar too high. If we're comfortable with solutions that will work on all mainstream PC platforms including Macs, then it is sufficient to overwrite partition tables with zeros. I have never heard of an OS installer that scans for deleted partitions, and worrying about the possibility of such a thing causing problems is unreasonable.
The most usual problem with your approach is recreating a set of partition tables exactly matching the old tables, while failing to wipe out a filesystem signature buried halfway into the disk. One reboot later, and magic header bytes start to be recognized as valid filesystems by whatever OS installer or BIOS utility you happen to be using. Even worse if you're been taking some hacky shotgun approach to blowing holes in the drive by zeroing out random sectors that belong to one of those recognized filesystems.
So once again,
> The only portable, reliable, robust way to accomplish this is wiping the drive
This is not remotely accurate. GPT is at the beginning of the disk, with a backup copy at the end of the disk. Wiping the GPT makes the layout of filesystem structures within partitions completely irrelevant. Wiping the primary GPT at the beginning of the disk is usually (possibly always) sufficient to make an OS installer believe the disk to be empty. The backup GPT at the end of the disk is something I've only seen used by manual partitioning tools that are more powerful and complex than the automatic partitioning tools that are part of OS installers.
> The most usual problem with your approach is recreating a set of partition tables exactly matching the old tables, while failing to wipe out a filesystem signature buried halfway into the disk. One reboot later, and magic header bytes start to be recognized as valid filesystems by whatever OS installer or BIOS utility you happen to be using.
Rebooting and re-detecting everything between partitioning and mkfs is not part of any ordinary OS installation procedure. Do you have any evidence that this failure mode can actually occur in practice with real shipping operating systems?
Remember, for the purposes of this hypothetical, we have to assume that at least one of the user or the OS installler is actually trying to make the process work. You can't assume that they're both trying to interfere with the process and are both going out of their way to cause problems.
At least Ext4 repeats the complete superblock at the beginning of every block group, so yes, it is not only remotely accurate, but entirely accurate. In the case of GPT, Linux requires explicit command line options to enable alternative GPT use, but do you know this is true for all systems in existence and all versions of Linux?
> Rebooting and re-detecting everything between partitioning and mkfs is not part of any ordinary OS installation procedure
Yes, I've personally bumped into this on desktop and unattended server installs - numerous times.
But you're externalizing the onus to prove cases where some hacky approach won't ever break when there is a vastly simpler way to avoid this entire class of problem. This is exactly the reverse of sound logic -- I'm offering you concrete real world examples of why you should avoid the hack and you're simply ignoring them
At this point I'm considering this not only to be offering up worst-practice advice, but actively trolling. Possibly the worst case of "a little knowledge is dangerous" I've seen recently. Regards
Name and shame, please. Because your spurious complaints about SSD write endurance haven't exactly established your credibility, and you do otherwise seem to be postulating that non-standard nonsensical actions will somehow insert themselves into the process under discussion.
> I'm offering you concrete real world examples of why you should avoid the hack and you're simply ignoring them
No, you're not offering any concrete real-world examples. You're offering hypothetical examples of how a malicious user might be able to trip up a non-specific hypothetical automated OS installer.
> At this point I'm considering this not only to be offering up worst-practice advice, but actively trolling. Possibly the worst case of "a little knowledge is dangerous" I've seen recently. Regards
You are the one who called something "bad advice" but three comments later have yet to prove that it could ever fail in practice. I'm not trolling, and I'm not saying that a dd to the first 1GB of a drive is the best way to clean a drive. I'm just taking exception to your unfounded claims about what "could" go wrong.
The recovery OS and 1TR are not data needed to be saved permanently (as in serial number and such, without which you cannot restore the device), you can recover them through DFU.
Data critical for being able to restore is in the SPI flash. (and it's assumed that some of it might be in other NVMe namespaces too)