eMMC Sanitization: Erase Groups and Separate Storage Areas

Short answer

Treat eMMC sanitization as a device-area and operation-scope problem. Identify which data is in the user area, boot areas and any other configured storage before choosing a removal operation. In mmc-utils, Sanitize is described as deleting the unmapped memory region. Running it alone must not be represented as deleting every still-mapped file or every storage area in the package.

A defensible release record connects the target data to a supported operation, a correctly selected area and range, successful completion, and an acceptance decision. An empty filesystem or a successful program exit cannot fill a missing coverage explanation.

Who this is for

This is a qualification guide for engineers handling owner-authorized embedded devices during refurbishment, decommissioning or board reuse. The Linux examples inspect configuration; they are not a model-qualified destructive procedure.

The mmc-utils examples were checked against upstream source revision c6692d5f9bf1ab6fbf5694a0b61477621cc4d016 on October 24, 2026. Record the actual installed build because distributions can package different revisions. Full JEDEC normative text and a target chip's removal guarantee were not available for this guide; do not use it to infer requirements or guarantees for an unidentified chip.

When to use this

Use this review before approving a wipe recipe that says only “erase eMMC” or “run sanitize.” It is useful when the board boots from the same storage that the operator intends to process, or when a filesystem partition has been mistaken for the whole embedded device.

Decide whether the board will be reused, sold or destroyed, and identify the confidentiality requirement. Preserve authorized retention or backup material before crossing a destructive boundary. A recovery copy must itself be included in the data-disposition plan if its contents are also meant to be deleted.

When not to use this

Do not execute a generic address-range example on an unknown chip. Stop when chip identity, boot dependency, supported removal mode or range units are unresolved. A bridge that exposes ordinary blocks may not expose the MMC control operations required by the chosen process.

Do not bypass boot-area protection merely to make a command run. If the approved procedure cannot cover required data, hold the board for engineering review or an approved alternative disposition. Keeping the operating system bootable and removing all confidential data are separate acceptance goals.

Workflow

1. Freeze the identity and area map

Record the board and chip part numbers, reported identity, platform firmware, Linux kernel, tool build and host connection. Correlate those observations with the board's storage design and exact chip documentation. Do not let a pathname such as mmcblk0 serve as the sole asset identity.

Make an area inventory with one row per configured region. Include the user area, two boot areas, any general-purpose areas and RPMB where present. Mark each as containing target data, excluded with a reason, or unresolved. A normal partition table describes subdivisions of one logical area; it is not a complete package map.

Linux exposes MMC boot partitions separately as mmcblkXboot0 and mmcblkXboot1. Their contents can include bootloaders and configuration required to start the platform. Write access is disabled by default to reduce accidental damage. This guide does not ask the operator to disable that protection.

RPMB is a replay-protected storage mechanism, not a synonym for the user area. Establish its actual use and supported disposition with the platform owner. Do not program an authentication key as an experiment or interpret inability to read protected data as proof of removal.

2. Collect read-only capability evidence

After identifying the correct MMC device and confirming that the platform permits the query, an EXT_CSD read has this form:

# Example path only: replace it after identifying the target.
mmc extcsd read /dev/mmcblk0

The example requests register information; it does not issue erase, trim or sanitize. It was checked by source inspection, not run against a device for this article. Appropriate operating-system privileges and a working MMC ioctl path are required. A permission error or failed query is a failed observation, not a negative capability result.

Retain the complete output internally. Review the applicable revision, SEC_FEATURE_SUPPORT, erase-group configuration and size, boot-area information, and SECURE_REMOVAL_TYPE where defined. Distinguish the configured removal type from the set of supported types. A tool's decoded text is a useful observation, but the chip's matching documentation must resolve its operational meaning.

3. Define ranges before selecting an erase variant

Erase operations act on addressed regions, and their alignment constraints depend on the applicable device configuration and operation. Filesystem allocation units and hardware erase groups are different concepts. Record the selected area, address units, start and end convention, capacity and alignment evidence before authorizing any write.

Do not mix a byte count from a storage inventory with a sector address accepted by an erase utility. Do not round a range outward into boot or other retained data without an explicit disposition decision. If a proposed range leaves a partial group unresolved, resolve it in the model-qualified procedure rather than improvising on the bench.

The upstream tool lists legacy erase, discard, secure erase, trim and two secure-trim stages as distinct variants. Their names are not interchangeable acceptance labels. Secure trim must not be reduced to an isolated first-stage command, and a legacy interface name does not establish that it is the preferred method for a newer device.

4. Connect mapped-data removal and sanitization

For a procedure that uses ordinary erase or trim followed by Sanitize, document what first makes the intended data eligible for the later operation. The unmapped-region scope of the latter does not authorize skipping the earlier coverage step.

Also determine which selected areas the exact device operation covers. Do not extrapolate a user-area sequence into boot-area or RPMB removal. A feature table showing Secure Trim, Secure Erase or Discard/Sanitise support for an eMMC family is an availability clue, not a complete instruction sequence or per-chip physical-erasure assurance.

Approve the destructive sequence only after obtaining the exact model and firmware guidance, supported state, required power conditions, timeout behavior and expected completion evidence. This qualification guide deliberately supplies no universal erase addresses or removal-mode register writes.

5. Record completion and handle exceptions

Use the approved environment with stable power and no competing use of the target areas. Retain the actual operation transcript, result, timing, error status and interruptions. Check device status using the model-qualified procedure rather than relying on the absence of a filesystem.

A timeout, reset, loss of communication or power interruption leaves an unresolved result until documented recovery semantics establish otherwise. Do not invent a universal resume rule or repeatedly reset a busy device. Segregate the board and obtain a supported retry or alternative disposition.

The final reviewer should compare covered areas with the original target-data map. Accept only when the method and evidence meet the release policy; otherwise preserve the exception and keep the asset on hold.

Verification checklist

• Chip, board, firmware and host path are correlated with the correct asset.
• The map distinguishes user, boot, general-purpose and protected storage as applicable.
• Capability observations are tied to a tool build and exact device documentation.
• Address units, area selection and alignment are explicit before any destructive operation.
• The evidence distinguishes mapped-data handling from unmapped-region sanitization.
• Completion and errors are recorded; every required area has a supported acceptance result.

Resale and evidence checklist

An internal release record should include asset identity, target areas, method, command sequence reference, tool version, completion evidence, exceptions and the approving reviewer. “User area processed; boot-area disposition unresolved” is a hold condition, not a whole-device success certificate.

Preserve the distinction between operational completion and adequacy for the destination. NIST SP 800-88 Rev. 2 uses verification and validation for those separate questions. The presence of a command named Sanitize does not itself assign the organization's accepted sanitization level.

What not to publish

Keep register dumps, serial numbers, RPMB material, provisioning secrets and customer data inside the authorized evidence system. Public examples must not expose authentication keys or private recovery content. Do not claim certification, chip-off resistance or forthcoming product support without evidence that specifically establishes it.

Common mistakes

Sanitize-only reasoning. An unmapped-region operation is not evidence that all currently mapped data was removed.

Processing just the visible filesystem. Separate boot or protected storage can require its own disposition decision.

Confusing a support bit with completion. Capability, selected mode, execution result and acceptance are four different facts.

Treating protection changes as cleanup. Changing write protection or provisioning an RPMB key is not a general data-removal method and can introduce irreversible consequences.

CliDeck workflow fit

A runbook can keep the area inventory, capability capture, authorization boundary and exception handling together. Attach actual device evidence to the asset's processing record when the approved workflow supports it. This is a process recommendation, not a claim that CliDeck currently implements an eMMC erase engine or validates chip firmware.

FAQ

Does mmc-utils Sanitize erase every live file?

Its documented scope is unmapped memory. Establish the preceding mapped-data handling and area coverage for the exact device instead of assuming a standalone invocation covers everything.

Are boot partitions part of an ordinary filesystem wipe?

Linux exposes them as separate device partitions. They need an explicit decision based on what they contain and the approved procedure; wiping a user filesystem does not establish their disposition.

Can a feature sheet replace a chip-specific procedure?

No. It can identify a feature family, but it does not settle range constraints, firmware behavior, protected-area treatment or completion semantics for the board in front of you.

Related guides

Review flash translation and coverage limits, compare UFS logical units and purge evidence, and distinguish cryptographic erasure from surviving key copies.

Verification note: qualification criteria, not a device trial

The read-only query and tool descriptions were reviewed against pinned upstream source and primary documentation. No eMMC was read, erased, trimmed or sanitized for this article. The checks describe evidence that a future operator must collect and review.