3 ms·

If 5% of a drive was rewritten I think that would be a reasonable time to interrupt the accompanying software driver and determine a reasonable response. It is

If 5% of a drive was rewritten I think that would be a reasonable time to interrupt the accompanying software driver and determine a reasonable response. It is not necessary for the drive to revert the full size of the drive, merely enough data to reduce the false positive rate from normal activity. I think the hangup is the assumption the drive has to do 100% of the work. It is only needed to accelerate the snapshots for restoration after an attack is detected. Determining whether the system is under attack and the correct response can be done in software. On a larger note the remapping engine in an SSD makes for a great primitive. It would be awesome if SSDs exposed this in a more general way.

dmitrygr 5y ago
then you'd need a lot more than 5% overcommit. That is just there to help with flash wear and hiding block death. Source: have written FTLs that shipped in products
- jdsully 5y ago
  Sure, but it could be use configurable. For the actual problem of a cryptolocker it's pretty easy to detect the entropy change. You'd really only need to see the diffs a few files to decide something bad was happening. In any case users don't expect snapshots to be free.
  - dmitrygr 5y ago
    Entropy is a poor way to detect cryptolockers. For example, many OSes encrypt user data in software (ntfs has "encrypt" built in and is it commonly used). SSD firmware is simply NOT the place to do this. This is the same reason we do not implement HTML parsers in the kernel or javascript runtimes in BIOS. Too high level of a concept in too low level of a place
    - jdsully 5y ago
      I see now my original comment was poorly written. I only intended to imply the SSD would be used for reverting encrypted files as part of a rolling snapshot. It would have to work in conjunction with traditional AV software to actually detect an attack. If it were actually used this way its not crazy the AV software would require the specific hardware it was designed for. I don't think we disagree the remapping hardware could be repurposed for assisting the creation of COW snapshots, though obviously the disk space wouldn't come for free.

dmitrygr 5y ago

then you'd need a lot more than 5% overcommit. That is just there to help with flash wear and hiding block death. Source: have written FTLs that shipped in products

jdsully 5y ago
Sure, but it could be use configurable. For the actual problem of a cryptolocker it's pretty easy to detect the entropy change. You'd really only need to see the diffs a few files to decide something bad was happening. In any case users don't expect snapshots to be free.
- dmitrygr 5y ago
  Entropy is a poor way to detect cryptolockers. For example, many OSes encrypt user data in software (ntfs has "encrypt" built in and is it commonly used). SSD firmware is simply NOT the place to do this. This is the same reason we do not implement HTML parsers in the kernel or javascript runtimes in BIOS. Too high level of a concept in too low level of a place
  - jdsully 5y ago
    I see now my original comment was poorly written. I only intended to imply the SSD would be used for reverting encrypted files as part of a rolling snapshot. It would have to work in conjunction with traditional AV software to actually detect an attack. If it were actually used this way its not crazy the AV software would require the specific hardware it was designed for. I don't think we disagree the remapping hardware could be repurposed for assisting the creation of COW snapshots, though obviously the disk space wouldn't come for free.