|
repiv posted:isn't "software" encryption basically free anyway since AES-NI became a thing, it's still offloaded to dedicated hardware, just hardware on the CPU instead of the SSD controller Sort of? Most of the work is done by the AESENC/AESDEC instructions, each of which perform one round of AES encrypt or decrypt on a 128-bit chunk of data stored in a SSE register. "Rounds" in cryptography means repeatedly doing the same set of mathematical transformations on the input data; more rounds makes brute force decryption more difficult. Looking at what one AES round entails, I don't think it should be a huge number of gates, nor should it be unfriendly to high clock speeds. I infer that Intel designed these to be ordinary SSE instructions which flow through the pipeline with the same timings as any other SSE math op. This is a different approach from the kind of accelerator instruction which tells a much more loosely integrated hardware block to go off and do its own thing for many thousands of cycles. Net throughput for one core is on the order of 10 bytes encrypted or decrypted per cycle, which starts to become a substantial amount of CPU time with multi-GB/s SSDs. You also have to consider the cache-trashing side effects. If you want full disk encryption, AES-NI is far better than no acceleration, but has real CPU and disk performance overhead compared to full offload. When you use OPAL to do that offload, your disk's firmware is now a critical security component. Unfortunately, the entire history of disk firmware says this is A Very Bad, No-Good, Rotten Idea - the miracle is that disks work at all, really. Many exciting security flaws have been found in many vendors' TCG-Opal implementations.
|
#
¿
Jan 8, 2024 00:36
|
|
|
|
| # ¿ May 10, 2024 17:19 |
|
|
WhyteRyce posted:lol someone dumped the pm9a3 firmware files and changelog here. for the curious, feel free to read the fw release notes and see a detailed description of what types of bugs you can hit on SSDs I haven't even gotten to reading the bugs yet but am floored by the fact that they send out release notes as excel spreadsheets
|
|
#
¿
Jan 8, 2024 00:45
|
|
|
Klyith posted:This might even be a case where consumer drives would be better than enterprise -- enterprise are assumed to be always on, while this it almost always off. Could be the data retention for mostly-turned-off is better on consumer ones. Retention starts out high when the flash is at 0 write cycles, because that's when the insulation around charge traps or floating gates is in excellent condition. As the flash accumulates write cycles, insulation gets damaged, making the cells leakier, which means they fade faster. However, people want a single number which tells them "this is the minimum guaranteed data retention time". NAND manufacturers spec the retention time based on the NAND having reached its rated write cycle limit, but this means that brand new NAND will always outperform its datasheet retention time, and not by a small amount either. This brings us to enterprise vs consumer. They do some binning, as I understand it, but that's not enough to produce the huge increases in write cycle endurance that enterprise NAND enjoys. Instead, they're just choosing to pick a point further out on the curve: more write cycles, worse retention. Enterprise customers are okay with retention times that would be terrible in a consumer product, but want the drive to last longer in service before it has to be scrapped, so they're fine with this tradeoff. So for this trade show demo application, consumer or enterprise makes no difference. Buy any new SSD, don't write to it a lot, and it should have multi-year power off retention regardless of its nominal specs.
|
|
#
¿
Mar 15, 2024 13:03
|
|
|
Klyith posted:Is there any tweaking or tuning for how much separation between the voltage levels is used? Or is that a thing that's not really possible to do? From the very basics I know of how the cells work, that seems like it would trade better retention (more gap between levels) for endurance (higher voltage putting more stress on the cells). Please note I am not a real flash expert, I just used to chat with an engineer friend who worked on enterprise SSD controllers so I learned some flash facts from him. No idea re: levels but if I had to guess, I'd guess it isn't possible. Just on first principles, the more electrons you shove in the trap, the more they want to get out. Doesn't seem like that would mix well with leaky insulation at end of life. On pSLC - multi-level write modes have worse write performance than SLC because the controller inside the flash chip has to titrate charge into the cell. They inject some, read to see where the cell's at, if it's too low loop until done. It does seem plausible that repeated cycles of applying high voltage to force a little more charge in causes more wear than a single big injection.
|
|
#
¿
Mar 17, 2024 05:17
|
|
|
Shumagorath posted:Are the various secure erase ops any worse on SSD endurance than a normal write cycle? I understand there’s deleting an AES key and forcing all cells to 1 or max_voltage…? When I looked at it on SATA drives, the ATA Secure Erase command permitted both of these implementation choices. Some manufacturers publish technical documentation which discloses how they do it. Others, you can infer based on observing how the drive behaves during a secure erase (mostly, how long does it take - 10 or more seconds hints at bulk erase, a few seconds suggests key destruction), or other factors like SMART stat counters before and after the wipe. Don't count on one vendor doing the same thing every time. IIRC, I found that Samsung 840 appeared to be a bulk erase family, while 850 used key destruction.
|
|
#
¿
Mar 20, 2024 00:06
|
|
|
|
| # ¿ May 10, 2024 17:19 |
|
|
WhyteRyce posted:In fact don't lots SSDs leave their internal encryption on because there is almost no overhead but you get the benefit of scrambling data and also the benefit of fast wipe? This is my understanding as well. People figured out that the best data pattern for improving bit error rate in flash is white noise, AKA no pattern at all. All good cipher algorithms generate output which looks just like white noise, and there are standard ones that are by design very cheap to implement as a hardware accelerator, so at this point if you aren't encrypting everything, you are designing SSD controller wrong. Once that's table stakes, it's not a big feature add to do secure erase by destroying the key. On the other hand, speaking of table stakes, if betting on finding plenty of incredibly boneheaded hardware and firmware design in PC peripherals was a thing, you could just plonk your money down on "there will be poo poo" every time and watch your winnings roll in.
|
|
#
¿
Mar 20, 2024 11:27
|
|