0

sfill -Illv makes a file with data from /dev/urandom until it fills the partition. Making a large file like this takes a lot of time. iotop tells me it is writing about 1 MB/s.

Though dd if=/dev/urandom >> ./randomfile, which would do the same thing, does this at about 12 MB/s. Why is sfill so much slower?

Edit: I am on stable Debian 11. The 12 MB/s number was writing to an ntfs partition on a mechanical hard drive. I tried two other Ext4 formated hds and got around 100 MB/s with dd. sfill still performs just as badly on those disks however.

1
  • Ah, let's ignore the NTFS then; even with the new in-kernel NTFS driver, it's a relatively slow file system. You being able to reproduce this on ext4 shows this is really an sfill issue, and not related to the performance of the file system. Mar 1, 2023 at 21:07

1 Answer 1

3

Comparative Benchmark

I wondered how slow sfill really was; so I benchmarked it:

Since I don't trust sfill (having read its source code, it feels more like an entry to the international obfuscated C code contest than well-written systems software that I'd trust to do something securely), I at least isolated it by running it in a VM, in which I ran it in a OCI container via podman, using a 1GB loopback-mounted XFS image as volume:

mkfs.xfs fsimage.xfs
udisksctl loop-setup -f fsimage.xfs
# I get a mountpoint automatically here
sudo mkdir /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test
sudo chown testuser:testuser /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test
podman run podman run --pull newer --rm -it -v /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test:/data:Z debian:11

In that I install apt install secure-delete, and run sfill -Illv /data. I run htop on the system and observe a write rate of 11 to 12 MB/s. So, 12 times as fast as your system – through about 4 layers of indirection ;)

Why is sfill -Illv slow?

I just read sfill's source code (link to archive checked into git repo; sigh… binaries in git. Security folks often aren't great software engineers; but this is just unnecessarily painful for all sides).

This piece of software hasn't seen love in the last 20 years, and honestly, it was terribly unclean 20 years ago. So, that was not a pleasure to read.

Anyway, at the heart of the sfill is opening files, filling them with data, and deleting them after.

So, by default, it opens that file with O_SYNC – for unspecified reasons. That guarantees bad performance, and there's absolutely no reason to not simply flush to disk at the very end.

Add a -f to your options to disable synchronous writing. For me, that sped up the write rate to roughly 130 MB/s.

For comparison, cat /dev/urandom > /data/tmpfile achieves nearly 500 MB/s; which is kind of to be expected, seeing that 1GB of write buffer isn't that much RAM.

Command Speed Speedup compared to your measurement
sfill -Illv /data     12 MB/s     12
sfill -Illvf /data   130 MB/s   130
cat /dev/urandom > /data/tmpfile ~ 500 MB/s ~ 500

Perusing perf top, it's plain to see that only cat /dev/urandom > /data/tmpfile actually starts to even involve the CPU ever so slightly into the performance bottleneck – my kernel's chacha_permute, part of the urandom (half-pseudo)RNG, actually appears.

So, synchronous writing still doesn't quite explain the abysmal performance, so I have to blame the rest on the highly inefficient way they generate random bits; *buf++ = (unsigned char) (256.0*rand()/(RAND_MAX+1.0)), seriously? That's not only unnecessarily doing floating point math, it's not even giving good randomness, which is twice as sad, as on modern GNU/Linux systems, RAND_MAX happens to be 2³¹, so you do get 31 bit of OK randomness, then you mangle it badly, and get 8 bit of bad randomness…

Lessons Learned

  • Don't expect 20 years dead software to be reasonably performant
  • Whenever you get software advertised for in the security researcher community, beware software quality
  • Sometimes, the easier solution is the better solution: Writing a file full of randomness until the free disk space is used up never needed a special program sfill; anything that produces random data, piped into a file until it fails due to full disk, which you afterwards delete, would have done the same
  • The Gutmann USENIX article is far from non-controversial. Relatively common agreement is that on modern storage and file systems, it's essentially barking up the wrong tree; modern hard drives are darn close to physical limits, so that the mutual information between previous writes and what you can even theoretically read out with as-precise-as-quantum-theory-allows measurements is low enough that you can't do much with that. The need to overwrite with random data is hence dubious.

Twice so, as technologically, it's a pretty safe bet that any hard drive since 1980 will have a so-called scrambler, which prepares the symbols going to the write head, so that writing a long line of zeros (or ones) doesn't lead to a constant signal; hence, overwriting your "secret" data with random bits doesn't look much more random to the physics of the magnetic medium than overwriting it with zeros – because these zeros would, just as the random data, get scrambled before being written. However, of course that scrambling sequence is inherently known, so if there actually is some residual magnetization from previous writes you could sense, then that would indeed have more information about the previous data. Again, this is not a physically relevant attack today.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .