wait... how do other systems such as APFS and ZFS do acceleration ? [LWN.net]

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 24, 2017 3:05 UTC (Fri) by johnjones (guest, #5462)
Parent article: Inline encryption support for block devices

As the title says how do other systems such as APFS and ZFS do acceleration ?

Also does not OCF (OpenBSD Crypto Framework) and other accelerators already do something like this ?

thanks

John

to post comments

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 26, 2017 2:00 UTC (Sun) by tytso (✭ supporter ✭, #9993) [Link] (4 responses)

It's not a question of how do other operating systems or file systems do acceleration; it's a question of how does the hardware do acceleration.

Historically, most accelerators work by sitting on the Host CPU's bus, and talks to the main memory. An example of this is an SHA256 accelerator which sits on the PCIe bus, and checksums data in memory. See the slides from a presentation[1] at the 2014 OpenZFS summit.

[1] http://open-zfs.org/w/images/6/63/Lightning_Talk-Zacodi_L...

What some ARM SOC (system on chip) vendors have done is to put an encryption engine in between the host CPU and the storage device. This isn't actually new; IBM Mainframes can do something similar. Interestingly, one of things ARM CPU's on handsets and Mainframe CPU's is that they tend to be relatively underpowered compared to the rest of the system. So while having a storage-specific accelerator between CPU and storage device is less flexible, it reduces the overhead on the CPU and memory. (For example, an encryption engine which can also be used for IPSEC would read from memory, and then write the ciphertext back to memory --- but then data would have to be sent from memory to the storage or networking device. Compare this architecture with one where you have a crypto engine just for storage, and a different crypto engine just for networking which lives on the NIC.)

I predict that in the future, we'll see this architecture on server platforms. Since we can no longer double the CPU frequency every 18 months, it makes more sense to speed up system by pushing more transistors away from CPU to more specialized hardware accelerators. And if that means specialized crypto engines for storage and networking --- that's just fine.

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 27, 2017 8:15 UTC (Mon) by ortalo (guest, #4654) [Link] (2 responses)

I agree this seems fine for spreading usage of crypto. acceleration.
However, it seems to me we are seeing the problem of sharing these devices between multiple users appear now ; especially in the use cases where different users expect to use different keys.
Admittedly, it is already very nice to have host encryption, if only to have host-level protection againts "outsiders".
However, I wonder if simple additions to these hardware would not allow association of different sets of keys to different users contexts (similarly to the way pagetables are associated to specific adress spaces in the classical MMU case)?

Another question: all these new hardware are targetting encryption only? Nothing with respect to signing (or hashing) only?

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 28, 2017 21:04 UTC (Tue) by tytso (✭ supporter ✭, #9993) [Link] (1 responses)

How you associate keys to different user contexts is a key management problem, which is somewhat orthogonal to crypto acceleration. If the keys are provided by the host CPU to the crypto engine, then supporting keys for different users is trivial. We do this today with the Pixel and Pixel XL. Separate keys are actually used for each user profile. This means that if you leave your company, and your company is using G Suite (e.g., Gmail, Google Drive, etc.) with enterprise domain management, your company can arrange to have the key associated with the corporate identity be erased from your Android device, while allowing you to keep your personal profile on your phone. (Previously the Android Device Policy Manager would have to wipe the entire device when you left the company.) And if you have multiple users on your phone, each user also has a separate key.

Right now, all of in-line crypto acceleration hardware which I am familiar with is targetting encryption only, unfortunately.

The challenge with doing authenticated encryption (e.g., AES GCM) is that you need to store the per-block authentication tag somewhere. The challenge is that doing this would mean we would need flash chips with page sizes that are 4k plus 32 bytes for the IV and AES GCM authentication tag. But there aren't any eMMC flash devices with 4128 byte pages. And a non-standard, custom eMMC storage device would be extremely pricey. So it would probably be not commercially viable. :-(

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 28, 2017 22:56 UTC (Tue) by tytso (✭ supporter ✭, #9993) [Link]

I should add there is one hardware crypto devices that you can find in most laptops that will do signing, and that's the TPM. A few months ago, James Bottomley blogged[1] about interesting ways to use the TPM, including as a way of securing your SSH keys. (That's actually an encryption function, not a signing function, but the TPM can also do signature operations. Still, it's a good introduction to the TPM technology, so it's worth a read.)

[1] https://blog.hansenpartnership.com/using-your-tpm-as-a-se...

But a TPM is really not a crypto *accelerator*; in fact, pretty much all TPM's are incredibly S-L-O-W at doing crypto operations. So why does a TPM exist? Because it will only encrypt, decrypt, or sign messages on your behalf if you give it the correct password or PIN. And if you try too many bad passwords, the TPM will lock you out. So this is useful if you want to protect someone from stealing your password, since the password by itself won't be enough; they will also need to be able to get your laptop. It's also really good at making Jim Comey, head of the FBI, really angry. Oh, well. :-)

You can certainly use a TPM, or some other secure element, in conjunction with an in-line crypto engine. The two technologies are very complementary. This is why I want to make sure that whatever inline crypto encryption support gets landed in the upstream kernel can be easily extended to support device designs where the host CPU does not have access to the encryption keys, and where the keys are provisioned via some kind of secure element directly to the inline crypto engine.

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 29, 2017 8:36 UTC (Wed) by robbe (guest, #16131) [Link]

> This isn't actually new; IBM Mainframes can do something similar.

Isn’t this the case for most HW features, that mainframes had it already in the 1970s? IBM is the Beatles of computer hardware.