Announcement

Collapse
No announcement yet.

FSCRYPT Inline Encryption Still Being Prepared For The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FSCRYPT Inline Encryption Still Being Prepared For The Linux Kernel

    Phoronix: FSCRYPT Inline Encryption Still Being Prepared For The Linux Kernel

    For a number of months now Google engineers have been working on FSCRYPT inline encryption capabilities for EXT4 and F2FS. The work is designed to offer better encryption performance on modern SoCs by having the encryption/decryption happen within the block layer as part of the bio and in turn leveraging the inline encryption hardware on modern Arm SoCs. The work still isn't merged but looks like it could be getting closer...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Apart from Android devices, is there any other hardware available that can use this? Are there any SSDs or NVMe drives that have inline encryption capabilities (that can be managed by the OS, not talking about things like Vertex 3 self-encrypting drives).

    Comment


    • #3
      Originally posted by AndyChow View Post
      Apart from Android devices, is there any other hardware available that can use this? Are there any SSDs or NVMe drives that have inline encryption capabilities (that can be managed by the OS, not talking about things like Vertex 3 self-encrypting drives).
      At the moment, not really. Inline encryption is part of the UFS standard which isn't Android-specific, but you'd only find it in other embedded devices. There is an NVMe inline encryption standard being worked on, but it's a bit different from the UFS one and it's unclear whether it will be useful. Note also that outside the mobile/embedded space, just using the CPU acceleration for AES is more viable so there's less of a need for anything special.

      Comment


      • #4
        Originally posted by AndyChow View Post
        Apart from Android devices, is there any other hardware available that can use this? Are there any SSDs or NVMe drives that have inline encryption capabilities (that can be managed by the OS, not talking about things like Vertex 3 self-encrypting drives).
        SSDs and NVMe drives normally don't have inline-encryption. Not everything inside Android devices is not inline either.

        The noted fall back "fallback to the kernel crypto API" this also allows Android devices with normal hardware accelerators to be picked up as well.

        Not the best example but you have SoC chips where hardware accelerators are exploded by the Crypto API so not inline.

        Yes normal hardware accelerators include the PCIe cards you find in servers that are also exposed by the Crypto API.

        Please note be it the "inline encryption hardware" or a "hardware accelerator" you can have the same problem of a fix number of encryption keys allowed system-wide at a time. So it might just make sense to unify all this code at the block layer instead of doing the key and processing queuing in the file system level..

        Originally posted by ebiggers View Post
        Note also that outside the mobile/embedded space, just using the CPU acceleration for AES is more viable so there's less of a need for anything special.
        Silicom’s Encryption Compression Offload Server Adapters are based on-chip Intel®, Cavium® and Freescale® production process that provides the best industry

        ebiggers servers you do find using accelerator cards because even the CPU acceleration for AES versions of encryption and denecryption can be slow in compare to the decanted accelerator cards even allowing for the PCI transfer overheads. Freeing server cpu up from processing encryption AES to be to other tasks can be another reason to use the accelerators.

        Correct line would have been "outside mobile/embedded and particular server workloads just using CPU acceleration for AES is more viable.

        Yes mobile+embedded+server that benefit from encryption accelerators of one form of another is quite a large market share. Yes it simple to overlook that inline encryption acceleration and decanted hardware accelerators do run you into the same set of problems with number of encryption keys allowed at any one time. So there is a need to do something special here to manage how and when stuff is processed by the accelerators and you really don't want to be doing that special on a per file system driver base.



        Comment

        Working...
        X