Re: Filling a device with random data

On 9 Feb 2023 16:01 +0100, from [email protected] (David Joaquín Shourabi Porcel):
> $ dd if=/dev/urandom of=/dev/null status=progress
> 4819285504 bytes (4,8 GB, 4,5 GiB) copied, 12 s, 402 MB/s^C
> 9708379+0 records in
> 9708378+0 records out
> 4970689536 bytes (5,0 GB, 4,6 GiB) copied, 12,379 s, 402 MB/s

That's doing I/O in blocks of 512 bytes, so syscall overhead is likely
to be a large limiting factor. (Each block requires at least a few
kernel/userspace context switches through syscalls; at an _absolute_
minimum, for each block, it's likely going to go through userspace dd
to kernel read through kernel /dev/urandom driver to userspace dd to
kernel write through kernel /dev/null driver to userspace dd.) Compare
and contrast that to a cryptsetup benchmark which is likely (I haven't
looked) primarily one or the other. If you want to gauge the
performance of /dev/urandom, I suggest trying with something like
bs=1M to reduce that overhead. Going from bs=512 to bs=1M I get an
about 60% speed increase, although it still comes up far short of a
cryptsetup benchmark (with bs=1M at about a quarter of the throughput
of the cryptsetup benchmark on my particular system). So for fast
storage media, going through a crypt mapping can still be beneficial,
although the degree of benefit will obviously depend on the relative
performance of CPU (including encryption instructions) and storage
device. Whether you use a plain dm-crypt mapping or a LUKS container
should be largely irrelevant for these purposes, however.

Similarly, when you're writing to a real-life storage device, doing so
in blocks of 512 bytes is going to utterly devastate performance
compared to using blocks on the order of tens of megabytes or even
larger. (I realize that's not what either of your tests do.)

Also, what kernel version are you running?

The major advantage to doing a separate full-disk write with a
throwaway key is that the data is going to be meaningless also through
the eyes of the final LUKS container mapping. Depending on your use
case, this can provide a slight confidentiality advantage.

Doing a full-disk overwrite pass on SSDs has its problems, though;
primarily that it forces the SSD to consider every user-accessible
block as being in use, hampering wear leveling. That becomes a far
more delicate balancing act between storage metadata confidentiality
(the full-disk overwrite hampers an attacker's ability to determine
what blocks are in use) and giving the SSD's firmware a decent chance
of doing wear leveling (for which you want to leave the underlying
storage pristine and perhaps also allow TRIM passthrough, but which
leaks information about which parts of the storage device are in use).

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”