[Slartie]

Thanks for the JS link, I didn't know about that. Though I would hardly call that "Javascript acceleration in hardware". They added a slightly weird float-to-int conversion command that handles overflows a bit different than the normal command, and for lack of better names (and probably because no one else is expected to require that quirky command) they put a "Javascript" into its name.

The perf hit with Filevault became practically zero when Intel added the AES encryption hardware into its chips, which was quite a while ago (and definitely long before the T2 was a thing). I don't remember exactly when that was, but I remember noticing a considerable difference, because I've used FDE since it became available in Filevault. It wasn't even on Macs only, my Windows machines also showed the same improvements using (IIRC) TrueCrypt back in the days.

The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.

[sudosysgen]

>The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.

I don't really see how that would help, CPU i/o has to handle the exact same amount of incoming data encryption or not. Maybe a bit less RAM impact though.

[Slartie]

My thought was this: If the CPU decrypts, it touches every byte being read to RAM, and it touches the data again later when it does actual work on it. If it doesn't decrypt, but a chip next to the NAND does the job, the CPU can DMA-transfer the data directly from that chip to RAM. The first time the CPU touches the data is when it actually does some real work on it.

[sudosysgen]

True, but my thought was that since AES decryption is mostly limited by RAM bandwidth anyways, the transfer from the SSD to the CPU, then from the CPU to the T2 chip, then from the T2 chip to the CPU won't be much faster than transferring from the SSD into the RAM, then decryption, then it being read back into the RAM.

[Slartie]

AFAIK the T2 is also the SSD controller in Apple's architecture, meaning it speaks directly to the NAND. So it should not be necessary for data to first go to the CPU, then to the T2 for decryption - the T2 can transparently decrypt and encrypt while doing the job of offering block-device-level access to the flash chips.