UFS Sanitization: Logical Units, RPMB and Purge Evidence

Short answer

A UFS sanitization claim needs three connected records: which storage was in scope, which removal behavior the device supports, and whether the intended operation completed. A readable logical unit, a successful reset, or a tool containing a purge control does not establish whole-package deletion.

Separate normal logical units, boot use, RPMB and any other platform storage holding target data. Capture capabilities and configuration before modifying anything. Then use a procedure qualified for the exact UFS device and host platform, with completion evidence and a release decision that explicitly addresses every required region.

Who this is for

This guide is for embedded-device and mobile-platform engineers qualifying an owner-authorized sanitization process. It focuses on Linux tooling and scope review, not a universal consumer-phone reset recipe.

The source examples were checked against ufs-utils revision 82157bb4f4e8f7934bf5ce13cdd7775616151e65 on October 24, 2026. Its README describes alignment to UFS 4.1, while some help tables retain earlier revision labels. Neither statement proves that an attached device implements every listed feature. Record the device's actual revision and the installed tool build.

Full JEDEC normative text and a target model's purge guarantees were not available for this article. The workflow therefore stops short of numeric status decoding or destructive instructions that would require those details.

When to use this

Use this review when a refurbishment procedure proposes “UFS purge,” “factory reset” or “whole-device erase” without an area map and a completion test. It is also useful when a board exposes several storage nodes and the operator is unsure which one corresponds to the intended package or logical unit.

First define whether the operation is intended to remove application data, all confidential platform data, or a narrower authorized set. The release destination and sensitivity determine the required assurance. Preserve retention decisions and authorized recovery material before a destructive operation is approved.

When not to use this

Do not apply a server SCSI sanitize recipe merely because UFS uses a SCSI-based command model. Protocol architecture does not imply support for every command in another storage class.

Do not set query flags, rewrite descriptors, reconfigure logical units or invoke RPMB operations on an unidentified board. Stop if the OEM procedure, firmware scope, protected-storage treatment or completion interpretation is missing. A production phone's security state can also prevent the engineering access used in Linux examples; that restriction is not evidence of sanitization.

Workflow

1. Map storage at the package and platform levels

Identify the board, UFS package, reported manufacturer/product information, firmware, host controller, driver and tool build. Correlate host storage nodes with the actual UFS device and logical-unit inventory. Do not assume that a familiar /dev/sda name uniquely identifies UFS or that the first visible block node covers every unit.

For each enabled logical unit, record its role, accessible capacity, target-data status and approved disposition. Record boot use and RPMB separately in the review. The platform design must also identify sensitive data outside the UFS package, such as another nonvolatile component or an external recovery copy.

An application reset can be an approved platform operation, but its name is not a coverage description. Ask which storage regions, keys and copies the exact implementation processes, and retain the answer with the procedure version.

2. Qualify the tool and read descriptor evidence

Begin with local help and version output from the approved tool binary:

./ufs-utils -v
./ufs-utils --help
./ufs-utils desc --help
./ufs-utils attr --help

These commands request tool information. They were reviewed in source, not executed against hardware for this article. Check that the installed build's syntax matches before using a device path.

After the host's UFS BSG node has been identified through its actual device inventory, descriptor reads can take this form:

# Example node only: replace it with the verified UFS BSG path.
./ufs-utils desc -t 0 -r -p /dev/ufs-bsg0
./ufs-utils desc -t 7 -r -p /dev/ufs-bsg0

In the reviewed implementation, descriptor type 0 is Device and type 7 is Geometry; -r selects reading. The examples require a compatible driver, control path and appropriate privileges. A missing node, rejected query or permission error is an observation failure to investigate. Do not switch randomly among block devices until a command happens to succeed.

Capture the supported removal-type field and configured removal-type field where defined for the reported revision. The implementation exposes names including bSupportedSecRTypes and bSecureRemovalType. Preserve both the raw result and the interpretation tied to the matching documentation. Avoid copying numeric encodings from an unrelated UFS generation.

3. Separate the storage-command and management paths

UFS has storage-command and device-management interfaces. A successful read through a logical block interface does not prove that the host can perform the required management operation, and a descriptor query does not show that target data has been removed.

Verify that the approved platform procedure reaches the intended device through the required path. Record any bridge, service mode, firmware restriction or transport limitation. Do not substitute a configuration write for a storage-removal step or assume that changing a logical-unit layout sanitizes the physical locations previously associated with it.

4. Specify what purge is intended to process

The procedure must establish which target data becomes eligible for the selected purge behavior, what areas are covered, what prerequisites apply and which supported removal type is selected. Resolve these questions for the exact device before any destructive trigger is sent.

In the reviewed tooling, fPurgeEnable is a write-only trigger, while bPurgeStatus is a readable attribute. Those are different evidence channels. Do not plan to read a write-only flag back as proof that a job finished, or count a successful request submission as the acceptance result. Use the model-qualified status interpretation and termination conditions.

No numeric success value, timeout or retry sequence is prescribed here. Without matching device and normative evidence, inventing those values would turn a useful capability review into an unreliable operating procedure.

5. Resolve RPMB explicitly

RPMB requires a separate scope decision. A historical Kioxia UFS 4.0 device-generation announcement, dated May 31, 2023, identifies Advanced RPMB and RPMB Purge capabilities. That is a specific implementation example; it must not be generalized to every UFS 4.0 package, older generation, production firmware or host stack.

Ask whether the actual part and platform expose the required operation, what data it covers, and which authorization and completion checks apply. An advertised feature does not prove that a particular service tool invokes it. Do not treat RPMB authentication as a cryptographic-erasure guarantee or assume that removing ordinary logical-unit data disposes of protected storage.

If RPMB can contain target data and its disposition is unresolved, record the gap and hold the asset. Do not provision a new key or alter protected configuration merely to explore what the tool can do.

6. Execute only the qualified procedure, then validate

Before execution, freeze the approved device identity, area map, firmware/tool versions, method, irreversible boundary and expected status transitions. Ensure stable power and the absence of competing use of the target storage.

During the actual operation, preserve command results, device status, timestamps, errors and interruptions. A timeout, reset or loss of communication is unresolved until the documented recovery procedure establishes the outcome. Do not assume that every implementation resumes after power loss or that repeated triggering is harmless.

After completion, compare the processed scope with the original target-data map and decide whether release criteria are satisfied. Logical read-back, where policy requires it, must state its population and detection limits. It cannot independently establish coverage of inaccessible physical flash.

Verification checklist

• Board, package, firmware and host paths are correlated with the correct asset.
• Enabled logical units, boot use, RPMB and external copies have explicit dispositions.
• Tool revision and device-reported capabilities are recorded separately.
• Descriptor reads and removal operations are not conflated.
• The purge trigger is distinguished from documented completion status.
• Errors and interruptions are resolved before the final scope-based acceptance decision.

Resale and evidence checklist

Retain an internal matrix of target areas, approved procedure references, actual results, exceptions and reviewer decisions. Include tool/firmware versions and the correspondence between host paths and the physical asset. Do not replace that record with a screenshot showing an empty home screen.

NIST SP 800-88 Rev. 2 distinguishes checking the operation's outcome from deciding whether the result is adequate. A board can be bootable after processing yet still have an unresolved data-disposition gap. Conversely, loss of bootability alone does not prove that target data was sanitized.

What not to publish

Exclude private descriptor dumps, device identifiers, credentials, RPMB material and customer recovery data from public reports. Do not advertise universal UFS purge support, certification or physical recovery resistance on the basis of a tool menu. No capability of forthcoming CliDeck software is established by this workflow.

Common mistakes

Treating a block node as the package. Record the relationship among the host path, logical unit and physical device.

Reading a trigger as a result. A write-only purge control is not a readable completion indicator.

Generalizing one generation's RPMB feature. Confirm support and access on the actual part and platform.

Equating reset with removal. Obtain the reset implementation's data and key scope before accepting that label.

Improvising after interruption. Retain the unresolved state and use supported recovery semantics.

CliDeck workflow fit

A runbook can make the area map, descriptor evidence and acceptance criteria reviewable before the irreversible step. Store actual results with the asset when the approved workflow supports that record. This is a process-design recommendation, not a claim that CliDeck implements UFS query, purge or RPMB functions.

FAQ

Does a UFS 4.1-aware tool prove my device supports every feature?

No. Tool awareness and device support are different facts. Match the actual device revision, part, firmware and host access path to the operation.

Can I use fPurgeEnable to check completion?

The reviewed implementation classifies it as a write-only trigger. Completion requires the appropriate status and error interpretation for the qualified procedure.

Does deleting all visible logical units settle RPMB?

No. Its data and supported disposition need an explicit, device-specific decision. A generic whole-device claim cannot conceal a protected-storage gap.

Related guides

Compare eMMC area and erase-group review, examine flash translation and physical coverage, and review cryptographic erase and surviving key copies.

Verification note: source review, not a purge experiment

The command forms and field distinctions were checked against pinned upstream source and primary documentation. No UFS device was queried, reconfigured or purged for this article. The operational checks describe evidence that must be collected during a future qualified procedure.