[HLD] SSD Wipe

[ShauliTaragin]

Repo	PR title	state
sonic-platform-common	[SED] Wipe SSD CLI
sonic-buildimage	[Mellanox] [SED] Wipe SSD CLI
sonic-utilities	[SED] Wipe SSD CLI

Summary

Adds the High-Level Design document for the SSD Wipe feature (config sed wipe-ssd), which securely erases the switch boot SSD in three sequential stages:

1. Ramdisk pivot — relocate rootfs to tmpfs so the physical SSD can be unmounted while the OS keeps running.
2. Crypto Erase (PSID Revert) — destroy the SED media encryption key via sedutil-cli (fast, key-based wipe).
3. NVMe Block Erase — overwrite all user data blocks via nvme sanitize --sanact=0x02 (slower, NAND-level overwrite).

The feature extends the SED framework adding:

• SedMgmtBase.wipe_ssd() + abstract get_psid()
• ssd_erase.sh orchestrator (ramdisk pivot + crypto erase + block erase)
• check_sed_crypto_erase_prereqs helper in the shared sed_pw_utils.sh
• rsync added to the image (needed by the ramdisk pivot)

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[benle7]

LGTM

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[bmridul]

Why is the command under "config".
This is not going to be a configuration. Its a one time execution. right?

[ShauliTaragin]

I put it under config as this feature extends the existing SED command group, which already provides the one-time config sed change-password and config sed reset-password operations. Keeping wipe-ssd in the same group provides a consistent SED management interface.

[bmridul]

Was HLD discussed in SONiC community?

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[ShauliTaragin]

Was HLD discussed in SONiC community?

Not yet. Presentation is in community slot tomorrow( September 1st)

[avinothcgl]

The current design logs to journalctl on a tmpfs that does not survive the reboot that follows the wipe. For any deployment with audit or compliance requirements, the wipe operation should produce a persistent, structured sanitization report that outlives the erase.

Pre-Erase Snapshot: ssd_erase.sh should capture drive and OPAL state before any destructive operation begins. This data is unrecoverable after the PSID revert, so it must be collected in the prereq/preparation phase and held in a shell variable or temp file on the tmpfs. Fileds(Drive serial number,Drive model,Switch hostname,Chassis serial,SONiC version,Operator user, timestamp,etc )

Post-Erase Verification: after crypto_erase and block_erase both return, the drive and TPM are still queryable from the ramdisk. The script should collect Sanitize State, TPM bank state, etc

The boot SSD is wiped and the tmpfs disappears on reboot, so the report must be sent out of the box before the operator reboots. At least two independent channels syslog or printing in serial console should be supported to publish pre/post erase state .

Without a persistent sanitization report, there is no auditable proof that the wipe occurred, what it covered, or whether it succeeded. The ramdisk environment has everything needed to generate and deliver this report

[Yarden-Z]

The current design logs to journalctl on a tmpfs that does not survive the reboot that follows the wipe. For any deployment with audit or compliance requirements, the wipe operation should produce a persistent, structured sanitization report that outlives the erase.

Pre-Erase Snapshot: ssd_erase.sh should capture drive and OPAL state before any destructive operation begins. This data is unrecoverable after the PSID revert, so it must be collected in the prereq/preparation phase and held in a shell variable or temp file on the tmpfs. Fileds(Drive serial number,Drive model,Switch hostname,Chassis serial,SONiC version,Operator user, timestamp,etc )

Post-Erase Verification: after crypto_erase and block_erase both return, the drive and TPM are still queryable from the ramdisk. The script should collect Sanitize State, TPM bank state, etc

The boot SSD is wiped and the tmpfs disappears on reboot, so the report must be sent out of the box before the operator reboots. At least two independent channels syslog or printing in serial console should be supported to publish pre/post erase state .

Without a persistent sanitization report, there is no auditable proof that the wipe occurred, what it covered, or whether it succeeded. The ramdisk environment has everything needed to generate and deliver this report

The SSD erase is a general procedure to run a disk wipe and clean process.
Here we describe the overall process to ensure that disk erasure is performed and done gracefully.

The auditing process to ensure disk erasure mentioned here is one thing, other vendors/auditors might require additional data that is not depicted here. If we would like to expand this to conform with auditing requirements - then I think this is a separate feature where we define the auditing process.

One vendor might claim that the report is sent prior to reboot and another vendor will require this report remain persistent throughout the wipe process.

I believe that these 2 should not be coupled and if a customer would like to ensure erasure and the correct auditing process complacency - its on the customer's side to develop and deploy this on top of the SSD wipe functionality instead of trying to enforce a uniform approach here that is not entirely covered and not 100% defined.

[ShauliTaragin]

The current design logs to journalctl on a tmpfs that does not survive the reboot that follows the wipe. For any deployment with audit or compliance requirements, the wipe operation should produce a persistent, structured sanitization report that outlives the erase.
Pre-Erase Snapshot: ssd_erase.sh should capture drive and OPAL state before any destructive operation begins. This data is unrecoverable after the PSID revert, so it must be collected in the prereq/preparation phase and held in a shell variable or temp file on the tmpfs. Fileds(Drive serial number,Drive model,Switch hostname,Chassis serial,SONiC version,Operator user, timestamp,etc )
Post-Erase Verification: after crypto_erase and block_erase both return, the drive and TPM are still queryable from the ramdisk. The script should collect Sanitize State, TPM bank state, etc
The boot SSD is wiped and the tmpfs disappears on reboot, so the report must be sent out of the box before the operator reboots. At least two independent channels syslog or printing in serial console should be supported to publish pre/post erase state .
Without a persistent sanitization report, there is no auditable proof that the wipe occurred, what it covered, or whether it succeeded. The ramdisk environment has everything needed to generate and deliver this report

The SSD erase is a general procedure to run a disk wipe and clean process. Here we describe the overall process to ensure that disk erasure is performed and done gracefully.

The auditing process to ensure disk erasure mentioned here is one thing, other vendors/auditors might require additional data that is not depicted here. If we would like to expand this to conform with auditing requirements - then I think this is a separate feature where we define the auditing process.

One vendor might claim that the report is sent prior to reboot and another vendor will require this report remain persistent throughout the wipe process.

I believe that these 2 should not be coupled and if a customer would like to ensure erasure and the correct auditing process complacency - its on the customer's side to develop and deploy this on top of the SSD wipe functionality instead of trying to enforce a uniform approach here that is not entirely covered and not 100% defined.

Additionally, I want to clarify that the current journal does survive the SSD unmount and erase. systemd-journald remains active in the ramdisk and records the operation through PSID revert, sanitize-status verification, and final completion. The operator is explicitly instructed to monitor the journal and reboot only after completion, allowing the execution record to be captured externally before reboot.
What does not survive is the local journal after reboot. Automatically generating and exporting a persistent structured audit report would be a separate auditing feature, as Yarden described.