|
|
|
|
|
|
by ericseppanen
3230 days ago
|
|
|
I don't think we can assume that all impractical attacks will eventually become feasable. There are some things that are not just hard, but computationally infeasable. Triggering random bit errors and expecting to pass both the LDPC error correction as well as the extra checksum probably falls in this category. I'm afraid I don't follow your suggestion that triggering SSD GC could somehow result in some other attack. This is simply the firmware automatically repairing the damage you were attempting to inflict. I don't see an additional attack vector here. Since flash is already an unreliable media, hardware & firmware already works very hard to conceal and silently repair any errors before they accumulate to a data corruption scenario. This is very different from a rowhammer-type attack because there is an active CPU that already works to prevent this type of damage when it occurs naturally (or due to a naive workload that reads hot locations often). |
|
|
I was thinking more of the wear-leveling of the NAND cells. (Sibling comment from wtallis points out that the entire technology is being phased out so that's pretty much covered then.)
What I had in mind was a write-spray to identifiable locations. Wear-leveling cycles cells out from active to inactive, and from inactive back to active. If you could prepare a whole bunch of cells with suitable patterns, AND had a way to get occasional cells cycled in uninitialised - then having predictable control over "where"[ß] a cell is cycled back in could allow to target the reads and writes to perform the attack.
We don't need control over which cells are cycled in if majority of incoming cells already have our data on them from their previous active incarnation.
ß: There is indirection above the physical cells and their addressing. I just don't know how many layers.