Join Us!

NVMe - filling it u...
 
Notifications
Clear all

NVMe - filling it up with random data (ISO 17025)  

  RSS
redrabbit
(@redrabbit)
New Member

We are an ISO17025 accredited lab. Recently during a review it was identified that we had an issue with NVMe storage drives - in that we didn't really have good policies around them.

We'd like to create a way of testing these with test devices, and also have a way of filling them up with random data.

I have heard of other standard SATA drives reading from the CMOS and filling up a defined proporation of each sector. Does this make sense?

Does anyone have any advice on this, is there a script that can achieve this or a better method?

Thanks

Quote
Posted : 15/05/2019 11:48 am
watcher
(@watcher)
Member

A vanilla dd will write the drives with zeroes or random data. dc3dd can also write selected patterns.

ReplyQuote
Posted : 15/05/2019 3:28 pm
AmNe5iA
(@amne5ia)
Active Member

sudo dd if=/dev/random of=/dev/sdb
Where sdb is meant to be the NVMe (I'm not sure how NVMe is listed in /dev in linux distros).

Should do the trick…

ReplyQuote
Posted : 15/05/2019 8:43 pm
Passmark
(@passmark)
Active Member

The above tests the ability to write to the drive (and does a good job of wiping the drive as well).

But it doesn't test that you can read the data back without error. So better to use pseudo random number stream with a known seed that can be later read back and verified. For this usage you don't need genuinely random numbers, just some that follow a uniform distribution. Also check the SMART data before and after the test to look for a increase in bad sectors. If you need more details let me know.

ReplyQuote
Posted : 16/05/2019 12:34 am
athulin
(@athulin)
Community Legend

We'd like to create a way of testing these with test devices, and also have a way of filling them up with random data.

How do you show or verify that you filled a drive with random data? The only way seems to be to refer to your source of random data to write, prove that you have implemented the 'filling' correctly (so that you're not random for just 255 of 512 bytes, say), or by doing some fairly extensive tests of randomness of the entire written data set.

Basically, you want to ensure that any third party can take a disk + a description of your method, and verify that the disk does not show any discrepancies from the method. Using all-zeroes or all-ones makes this easy (though see below) if you insist on all-random … you're at the mercy of issues of interpretation of randomness or bugs in the validation code. You probably don't want that – if you do, you basically have to specify what pseudo-random number generator you used, and how you set it up.

Though if you're a stickler for correctness, that third party may not be able to say, for an all-zero disk that *you* created it. If your methods specify that *you* do the job, and not someone else, how do you show that you wrote this particular all-zero disk?

In such case, I think it may be desirable to show that a particular sector of all-zeroes or all-ones or all-random does indeed come from your script or other code, and not has been placed there by any other means. So I would suggest initializing the sector, then overwriting some part of it by your own 'stamp' identifying you, the date/time the write took place, as well as the sector address that this content is intended for. (I'd probably also add a special byte at the last byte of the sector just in case there's may be a sector size issue somewhere. But that's probably paranoia speaking.)

Easiest way to avoid don't get into too much checkable details in your method …

I have heard of other standard SATA drives reading from the CMOS and filling up a defined proporation of each sector. Does this make sense?

Not really. You probably need to explain exactly what CMOS you are referring to, and the circumstance the drives do what you say
A reference to a manufacturer's HDD specification where this is documented is enough.

ReplyQuote
Posted : 16/05/2019 7:02 am
jaclaz
(@jaclaz)
Community Legend

Well, you should verify that the NVME device (the specific drives involved) do support the SECURE_ERASE (or a similar function, like ATA devices) in the firmware (they should) and then initiate that.

Whenever available (and provided that they are correctly implemented in the specific device make/model) the internal firmware commands are to be preferred because
1) they are faster than external commands
2) (generally speaking) they cannot be (accidentally) interrupted
3) they can usually "reach" areas of the device that are not otherwise normally accessible from the (higher level) OS commands such as dd.

Specifically for SSD's (NVME or not) I believe that dd or similar are not anymore up to the task (think of just the overprovisioning area).

Parted magic provides a GUI tool for doing that
https://partedmagic.com/nvme-secure-erase/
but *any* Linux distro should have the possibility to use the nvme-cli tools that allow to wipe the device (-s1 option)
http//blog.pythonaro.com/2018/05/how-to-securely-wipe-nvme-drive.html
https://github.com/linux-nvme/nvme-cli/blob/master/Documentation/nvme-format.txt
or
https://www.naraeon.net/en/other-naraeon-products/latest-naraeon-secure-erase/

The above are just examples, never actually tested any of those programs.

jaclaz

ReplyQuote
Posted : 16/05/2019 8:11 am
raydenvm
(@raydenvm)
Junior Member

Alas, dd with /dev/random has two downsides.

1. It's a time-taker to wipe a drive completely.

2. More importantly, modern QLC drives will wear-out due to low endurance. Some low-end models can even die after less than 100 full rewrites.

Therefore the most ecologic method is using Format NVM command with Cryptographic Erase enabled. It is also what's recommended in NVM Express Base Specification.

One of the simplest ways would be using nvme CLI tool in Linux. Here is the nice guide
https://tinyapps.org/docs/nvme-secure-erase.html

ReplyQuote
Posted : 17/05/2019 9:41 am
trewmte
(@trewmte)
Community Legend

Great range of views in this post.

This thread did make me wonder about NVM wiping and reminded me of comments by Bruce Nikkel in his book 'Practical Forensic Imaging - Securing Digital Evidence with Linux Tools (2016)'. Under Chapter 7 'Secure Wipe a Storage Device', Bruce records

"When you’re wiping drives, ensure the DCO and HPA have been removed. With NVME drives, make sure each individual namespace has been wiped (most consumer NVME drives have only a single namespace)." Page 226.

Therefore the most ecologic method is using Format NVM command with Cryptographic Erase enabled. It is also what's recommended in NVM Express Base Specification.

NVM Express Base Specification - NVM Express Revision 1.3d March 20, 2019 (Ratified) states

"The Format NVM command shall fail if the controller is in an invalid security state (refer to the appropriate security specification, e.g., TCG Storage Interface Interactions Specification). The Format NVM command may fail if there are outstanding I/O commands to the namespace specified to be formatted. I/O commands for a namespace that has a Format NVM command in progress may be aborted and if aborted, the controller should return a status code of Format in Progress." Page 175

One of the simplest ways would be using nvme CLI tool in Linux. Here is the nice guide
https://tinyapps.org/docs/nvme-secure-erase.html

raydenvm seeking clarification. Is the namespace issue (above) overcome by using the process adopted for nvme CLI tool?

ReplyQuote
Posted : 17/05/2019 10:01 pm
raydenvm
(@raydenvm)
Junior Member

This thread did make me wonder about NVM wiping and reminded me of comments by Bruce Nikkel in his book 'Practical Forensic Imaging - Securing Digital Evidence with Linux Tools (2016)'. Under Chapter 7 'Secure Wipe a Storage Device', Bruce records

"When you’re wiping drives, ensure the DCO and HPA have been removed. With NVME drives, make sure each individual namespace has been wiped (most consumer NVME drives have only a single namespace)." Page 226.

No problem. nvme CLI runs format command with the default that erases all namespaces in the NVM subsystem. It just works.
http//manpages.ubuntu.com/manpages/bionic/en/man1/nvme-format.1.html

NVM Express Base Specification - NVM Express Revision 1.3d March 20, 2019 (Ratified) states

"The Format NVM command shall fail if the controller is in an invalid security state (refer to the appropriate security specification, e.g., TCG Storage Interface Interactions Specification). The Format NVM command may fail if there are outstanding I/O commands to the namespace specified to be formatted. I/O commands for a namespace that has a Format NVM command in progress may be aborted and if aborted, the controller should return a status code of Format in Progress." Page 175

raydenvm seeking clarification. Is the namespace issue (above) overcome by using the process adopted for nvme CLI tool?

If NVMe drive still has I/O commands, Format NVM fails. It's logical. And it's easy to handle with a reset.
https://www.mankier.com/1/nvme-reset

So it would simply be something like this

nvme format /dev/nvme0

# if failed, run the following two commands

nvme reset /dev/nvme0
nvme format /dev/nvme0

ReplyQuote
Posted : 18/05/2019 7:00 am
trewmte
(@trewmte)
Community Legend

No problem. nvme CLI runs format command with the default that erases all namespaces in the NVM subsystem. It just works. http//manpages.ubuntu.com/manpages/bionic/en/man1/nvme-format.1.html

If NVMe drive still has I/O commands, Format NVM fails. It's logical. And it's easy to handle with a reset.
https://www.mankier.com/1/nvme-reset

So it would simply be something like this

nvme format /dev/nvme0

# if failed, run the following two commands

nvme reset /dev/nvme0
nvme format /dev/nvme0

Thank you.

ReplyQuote
Posted : 18/05/2019 9:00 am
Share: