dStroy - Flashcard Secure Wipe

Answer

NOTE:
This function meets DoD standards and is commonly used by commercial customers in addition to the US federal sector.
The user MUST remain connected to the CLI while the DStroy process is running (aprox. 3hrs).
 

These systems have third-party certification for this process.  The third party is "Kroll" (http://www.krollontrack.com/).  The PDF files containing Exec Summaries and Tech Summaries are attached.  These PDFs may be forwarded to customers as needed.

FlashSystem 810_ Kroll Ontrack EVS Exec Summary 5055172.pdf

FlashSystem 810_ Kroll Ontrack EVS Tech Report 5055172.pdf

FlashSystem 820_ Kroll Ontrack EVS Exec Summary 5055172.pdf

FlashSystem 820_ Kroll Ontrack EVS Tech Report 5055172.pdf

You can also find this information and reports for the 840, in the wiki article for that erasure process, here: How to Erase (dStroy) a Flash Module Completely

To permanently destroy all data on any or all of the flashcards, please perform the following:
The dStroy function is available in diagnostics mode. You need to login with admin credentials.

**Warning:** You should only enter this shell under the guidance of
             Technical Support.
**Warning:** Entering the diagnostic menu will interrupt system activity
             and may affect data currently on the system.  A full backup
             is strongly recommended before entering the menu.
             Confirmation to enter the menu will disable the
             fibre channel links.

Are you SURE that you want to enter the diagnostic menu? (YES/NO)
YES

**Warning:** Exiting this shell uncleanly may leave the system in an
             OFFLINE state.

Disabling links...

Entering the diagnostic menu ...

Choose a diagnostic command to run:

 1) Flashcard Format               (DESTRUCTIVE!) - Format any or all of the flashcards
 2) Cancel Patch                                  - Remove a patch image from being applied
 3) Configuration Reset            (DESTRUCTIVE!) - Reset any or all of the configuration
 4) Factory Default                (DESTRUCTIVE!) - Reset system configuration back to factory defaults
 5) Modify Storage Mode            (DESTRUCTIVE!) - Modify the System Storage Mode
 6) Start Flashcard dStroy Process (DESTRUCTIVE!) - Permanently destroy ALL data on any or all of the flashcards
 7) Force Flashcard into Read-Only Mode (DESTRUCTIVE!) - Force single flashcard into Read-Only Mode
 8) Recover Flashcard data                        - Attempt to recover lost data from Flashcard
 9) Config Stats Tracking                         - Enable/Disable non-essential interface stats tracking
10) Force Flashcard Shutdown                      - Shutdown flashcards who are not properly communicating
q ) Exit diagnostics menu

**WARNING:** Running this diagnostic command may destroy data and/or Logical Unit
               configuration.  A full backup is necessary for data integrity.

Are you sure you want to run this DESTRUCTIVE diagnostic command? (YES/NO)
All data may become invalid upon confirmation...
YES

Enter the flashcard to run dStroy on, or "all" to run dStroy on all flashcards (q to exit): ...

Available flashcards:
flashcard-1
flashcard-10
flashcard-11
flashcard-12
flashcard-13
flashcard-14
flashcard-15
flashcard-16
flashcard-17
flashcard-18
flashcard-19
flashcard-2
flashcard-20
flashcard-24
flashcard-3
flashcard-4
flashcard-5
flashcard-6
flashcard-7
flashcard-8
flashcard-9

flashcard-1

Please enter a dStroy command: (q to exit)
quick      - Erases all flash blocks
normal     - Erases all flash blocks, and verifies that they have been erased
long       - Erases all flash blocks, does writes of various patterns, erases again, and then verifies the erase
abort      - Aborts any dStroy process currenting running
 

Destroy the contents of a flash card: IBM FlashSystem (formerly TMS) dStroy Function

dStroy Procedure
================
The dStroy function of an IBM FlashSystem systematically ensures that all data resident in flash is erased. Each flash board has an on-board processor that takes the dStroy command and follows the procedure detailed below.
There are three dStroy modes: Emergency, Normal, and Extended.
They will be discussed in detail at the end.

Block Selection:
================
Before going into the actual procedure, flash block selection needs to first be discussed. The dStroy attempts to erase every physical block on the flash board, with the exception of those blocks marked bad by the chip manufacturer (BBT). We do not select the manufacturer bad blocks because our flash boards do never ever allow access to these blocks, the number of erase and write failures to these block would make verifying a board dStroy confusing, and they would need to be re-written to restore the bad block indicator.
This does, however, include any bad block we have determined to be bad since the board was built. We select these non-manufacturer bad blocks to ensure that any data that may have written to that block prior to it being marked bad is erased. The downside is that this increases your number of dStroy errors encountered, depending how these blocks have failed.
This block selection also includes any blocks currently hidden to the user because of the wear-leveling algorithm. When we state we act on "all blocks", we are referring to this block selection criteria.

Erase All Blocks (quick):
=================
This step wipes out all the data contained in the flash.
- The board clears the internal flash mapping tables (physical to logical addressing and the like).
- Three erases are issued to every flash block (see Block Selection above). If an erase fails, the block is added to the error list (up to 100).
- If more than 100 errors have been found, the dStroy fails.
- For each block in the error list, retry erasing the block 3 more times.
- If this is an Emergency dStroy, fail the dStroy if any of these erases fail and print all the failures to the log. Otherwise exit without a failure. This step takes under a minute.

Verify Erase (normal):
=============
This step reads all of flash and verifies that the contents are completely erased (all One's).
- Read each page in flash (64 pages per block) and verify that it is completely erased. The FPGA flash controllers actually read in the data and indicate if it is erased, and the on-board CPU checks the status. If either the read fails or the page is not completely erased, the page is added to the error list (up to 100).
- If more than 100 errors have been found, the dStroy fails.
- For each block in the error list, retry reading the page.
- If any pages fail the re-read, dStroy is failed and the failed pages are printed to the log. Otherwise the dStroy is complete and exits without failure. The time this takes varies from product to product, but should be on the order of a few hours.
 

Extended Overwrite (long):
===================
This step overwrites all of the blocks twice, first with a pattern and then it's complement (to ensure all bits get toggled). The following occurs only if this is an Extended dStroy.
- Write all flash blocks with a pattern. This pattern is generated by the FPGAs that are connected to flash. If a write fails, it is added to the error list (up to 100).
- If more than 100 errors have been found, the dStroy fails.
- For each block in the error list, retry the write.
- Erase all of the blocks again (same procedure as above).
- Repeat all above steps (including the erase), except the pattern's complement is used instead. The time this takes varies from product to product, but should be on the order of 1 hour.
NOTE: Unlike magnetic media, we've found no evidence that this is necessary with flash media. To the best of our knowledge when you erase flash, there is no "residual" data that can be recovered. However, we provide this additional feature for those people that are more comfortable with seeing the flash overwritten

Handling Errors:
================
Because we attempt to erase, read, and possibly write blocks that we have previously determined to have failed, there is a decent likelihood that there will be dStroy failures of some sort. Currently we lack any diagnostic tools for the user to actually read the contents of the failed blocks. We can, however, provide the user with a list of bad blocks we discovered before shipping the board. These blocks would never have been written by the user, and thus could be considered safe.
Ultimately, it is up to the customer to decide if the failures warrant further action or not releasing the board. We have done the best that we could in the confines of our hardware architecture and the commands provided by the flash manufacturer. However, we cannot control how the flash fails.

dstroy (long / normal) hang at 49% when tablespace is created. A workaround is to reboot the system and let the FlashSystem re-create the tablespace.
Afterwards clean up hardware log.
a) GUI or CLI: system reboot
b) CLI: "diag" --> "1  ) Flashcard Format " --> "all" (answer all question with 'Yes')
c) GUI: LOGS -> Clear Error LOG / CLI: log hwerr clear

dStroy modes:
=============
The modes are more-or-less detailed above in the procedure, but here is a quick synopsis.

- Emergency: Erases all flash on the board and reports any erase failures. This is intended for wiping the board when either there is not enough time to verify it is wiped or when that level of security is not required.

- Normal: Erases and verifies the erasure of all of flash. Any failure in verifying the erasure of data is reported. This is what we think the typical security-conscience customer will use to wipe the data from a flash board.

- Extended: Erases all of flash, rewrites and erases it twice more, then verifies that all data is erased. Any failure in verifying the erasure of data is reported. While we do not think this adds any real level of security, some customers might feel more comfortable with the data being overwritten a few times.