5 ms·

It's actually a great place to perform some types of mitigations (I'm not sure if these are done by this specific product though). Here's an example: A ransom

It's actually a great place to perform some types of mitigations (I'm not sure if these are done by this specific product though). Here's an example: A ransomware attack will rewrite large sections of the drive. Initial phases aren't distinguishable from things like updates but as it progresses the intent becomes more clear. An SSD can leave a ring buffer of old blocks around and transparently revert back if an attack is discovered. You could also do this as part of the filesystem, but the SSD already has to perform wear levelling and so is quite adept at transparently remapping blocks. It also has the benefit of hardware acceleration in the controller. It's not necessarily a bad place to implement the recovery.

duskwuff 5y ago
> Initial phases aren't distinguishable from things like updates but as it progresses the intent becomes more clear. I'm not convinced it does at all. Encrypting a bunch of files one by one is going to be indistinguishable at the block layer from other common operations like updating software, transcoding media files, or creating a compressed archive. Besides, I still haven't heard a convincing argument that the SSD controller could detect and respond to this any better than the OS could. At best, it might be able to do a poor job of it.
- jdsully 5y ago
  The SSD is not there to do the detection but to allow fast reverts of encrypted files once it is detected. Remapping blocks is a core operation for creating COW snapshots and the SSD already has to do it quickly for wear levelling. Software like LVM can already create snapshots at the block level but being software it has a performance penalty the SSD would not have. Traditional AV software still has to do the detection and its capable of that long before the entire drive is rewritten.
rasz 5y ago
"large sections of the drive" are virtual in SSD. Overwriting a file doesnt mean rewriting same sectors, and once system TRIMs a piece of disk it stops existing. For this to work Disk device would have to understand file systems, be able to decode NTFS etc.
- jdsully 5y ago
  To better understand this consider LVM - it does not understand the filesystems on top of it yet it can still restore from a snapshot. Unfortunately LVM snapshots suffer from performance penalties an SSD could avoid.
  - dmitrygr 5y ago
    Modern SSDs have maybe 5-8% overcommit. Where do you presume a 1TB SSD will snapshot 900GB of my documents as they are overwritten with 900GB of encrypted data? 900 + 900 > 1024...
    - jdsully 5y ago
      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.

duskwuff 5y ago

> Initial phases aren't distinguishable from things like updates but as it progresses the intent becomes more clear. I'm not convinced it does at all. Encrypting a bunch of files one by one is going to be indistinguishable at the block layer from other common operations like updating software, transcoding media files, or creating a compressed archive. Besides, I still haven't heard a convincing argument that the SSD controller could detect and respond to this any better than the OS could. At best, it might be able to do a poor job of it.

jdsully 5y ago
The SSD is not there to do the detection but to allow fast reverts of encrypted files once it is detected. Remapping blocks is a core operation for creating COW snapshots and the SSD already has to do it quickly for wear levelling. Software like LVM can already create snapshots at the block level but being software it has a performance penalty the SSD would not have. Traditional AV software still has to do the detection and its capable of that long before the entire drive is rewritten.

rasz 5y ago

"large sections of the drive" are virtual in SSD. Overwriting a file doesnt mean rewriting same sectors, and once system TRIMs a piece of disk it stops existing. For this to work Disk device would have to understand file systems, be able to decode NTFS etc.

jdsully 5y ago
To better understand this consider LVM - it does not understand the filesystems on top of it yet it can still restore from a snapshot. Unfortunately LVM snapshots suffer from performance penalties an SSD could avoid.
- dmitrygr 5y ago
  Modern SSDs have maybe 5-8% overcommit. Where do you presume a 1TB SSD will snapshot 900GB of my documents as they are overwritten with 900GB of encrypted data? 900 + 900 > 1024...
  - jdsully 5y ago
    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.