5 ms·

This paper is nonsense. The workloads presented aren't what wear levelling was designed for. You might have files on your hard drive which are written to many t

by blagie 4y ago

This paper is nonsense. The workloads presented aren't what wear levelling was designed for. You might have files on your hard drive which are written to many times per second. This includes some log files (e.g. a web server access log), some types of database files, as well as sometimes access time on files you just read (unless you set noatime on your file system, which is a really good idea). Wear levelling was implemented because drives *were* failing, quickly (in a few months). An attacker, if they targetted this, might be able to break your SSD in about 15 minutes, just by writing the same block over and over. That might even be possible with careful engineering of things like browser storage. With wear levelling, I've *never* had an SSD wear out. Almost no matter the write amplification and access pattern, they *won't* wear out. A typical SLC drive will be able to handle 100,000 writes. Writing 1TB at 300MB/sec is about an hour. 100,000 hours is about 11 years, of writing data at pretty close to peak SATA capacity. That doesn't mean they won't fail, but not like that. Making an open source SSD, and implementing a sane layer with things like capacity variance and a file system designed for SSDs makes complete sense, but not for crazy reasons like this one. A good reason, which I think was first raised by Alan Cox (or another of the kernel developers), is that some techniques designed to make hard drives reliable to power failures have the opposite effect on SSDs. SSDs write in larger blocks, and an interrupted write can wipe out unrelated data.

slaymaker1907 4y ago
I don't think an attack like you describe would be feasible (assuming FS support of capacity variance) unless the target drive was near maximum capacity which already causes issues with write amplification. You're assuming that an attack could write the same block over and over, but that's not simple even with capacity variance since you'd still need GC. The difference is that GC would only consider empty and partially empty blocks whereas wear leveling might move data from a completely utilized block (note I'm talking about a flash block which is much larger than an FS block). Suppose your SSD had the following blocks where E means erased and x means deallocated (so it is free, but you would need an erase to use it.: B0: [1,x,4] B1: [x,E,E] B2: [3,10,x] B3: [11,12,13] With wear leveling, a write to address 4 might consider erasing B3 as it moves things around even though it is fully utilized and contiguous addresses because B3 might have much fewer writes than the other blocks. Capacity variance would instead use all available blocks and merely stop using any block that gets too many writes. Equalizing writes among your working set of blocks that get data updates isn't too difficult, it's the RO data that gets tricky to work around. In fact, something the paper doesn't discuss but it is totally possible with current APIs would be for a drive manufacturer to just increase the amount of storage held in reserve for GC and hide that extra capacity from the OS. As blocks go bad, you just decrease capacity in the hidden area until the drive gets to the point where it no longer has enough reserve capacity for efficient GC at which the drive reports failure. I think manufacturers may do this already if they detect a bad block, the proposal would just add in extra conditions for when the drive considers a block failed. One weakness of the paper is they don't discuss how fast drive capacity would decrease over time.
- blagie 4y ago
  I think my post was unclear. The attack (and rapid wear) were both in the absence of wear levelling (of which capacity variance is a form). My points, which I admit got lost in there: 1) With wear levelling, write amplification doesn't matter much, since you have nearly infinite life in either case. SSDs fail, but only in highly esoteric scenarios due to going over write limits. 2) The write patterns in the paper make no sense, relatively to real-world usage patterns, or what wear levelling is trying to address.
kasabali 4y ago
> Almost no matter the write amplification and access pattern, they won't wear out. A typical SLC drive will be able to handle 100,000 writes. Writing 1TB at 300MB/sec is about an hour. 100,000 hours is about 11 years, of writing data at pretty close to peak SATA capacity. Quoting SLC endurance cycle numbers is disingenuous. Try 3000/1000 cycles which are more realistic for consumer TLC/QLC drives and it suddenly becomes less impressive. It'll become even less impressive when PLC/HLC cells are deployed in consumer space.
rasz 4y ago
Link some currently manufactured and available consumer oriented SLC drives :)

by blagie 4y ago

slaymaker1907 4y ago

I don't think an attack like you describe would be feasible (assuming FS support of capacity variance) unless the target drive was near maximum capacity which already causes issues with write amplification. You're assuming that an attack could write the same block over and over, but that's not simple even with capacity variance since you'd still need GC. The difference is that GC would only consider empty and partially empty blocks whereas wear leveling might move data from a completely utilized block (note I'm talking about a flash block which is much larger than an FS block). Suppose your SSD had the following blocks where E means erased and x means deallocated (so it is free, but you would need an erase to use it.: B0: [1,x,4] B1: [x,E,E] B2: [3,10,x] B3: [11,12,13] With wear leveling, a write to address 4 might consider erasing B3 as it moves things around even though it is fully utilized and contiguous addresses because B3 might have much fewer writes than the other blocks. Capacity variance would instead use all available blocks and merely stop using any block that gets too many writes. Equalizing writes among your working set of blocks that get data updates isn't too difficult, it's the RO data that gets tricky to work around. In fact, something the paper doesn't discuss but it is totally possible with current APIs would be for a drive manufacturer to just increase the amount of storage held in reserve for GC and hide that extra capacity from the OS. As blocks go bad, you just decrease capacity in the hidden area until the drive gets to the point where it no longer has enough reserve capacity for efficient GC at which the drive reports failure. I think manufacturers may do this already if they detect a bad block, the proposal would just add in extra conditions for when the drive considers a block failed. One weakness of the paper is they don't discuss how fast drive capacity would decrease over time.

blagie 4y ago
I think my post was unclear. The attack (and rapid wear) were both in the absence of wear levelling (of which capacity variance is a form). My points, which I admit got lost in there: 1) With wear levelling, write amplification doesn't matter much, since you have nearly infinite life in either case. SSDs fail, but only in highly esoteric scenarios due to going over write limits. 2) The write patterns in the paper make no sense, relatively to real-world usage patterns, or what wear levelling is trying to address.

kasabali 4y ago

> Almost no matter the write amplification and access pattern, they won't wear out. A typical SLC drive will be able to handle 100,000 writes. Writing 1TB at 300MB/sec is about an hour. 100,000 hours is about 11 years, of writing data at pretty close to peak SATA capacity. Quoting SLC endurance cycle numbers is disingenuous. Try 3000/1000 cycles which are more realistic for consumer TLC/QLC drives and it suddenly becomes less impressive. It'll become even less impressive when PLC/HLC cells are deployed in consumer space.

rasz 4y ago

Link some currently manufactured and available consumer oriented SLC drives :)