Ryzen crypto co-processor

[Glasspelican]

While QAT is far from receiving universal support, it is a multi-generational Intel accelerator technology that is popular in the embedded systems market. AMD does not have a compatible accelerator platform at this time but Intel offers QAT on PCIe cards or via chips if that is absolutely required.

I have been doing some tooling around in illumos trying to use rdrand/rdseed to help feed the os rng pool. For curiosity's sake I was trying to figure out/find documentation on how the entropy source underlying these instructions related to numa. Documents like this pdf talk about how the entropy source works, but dont help with the thing
i was trying to figure out.
The first lines of the introduction to that pdf do say something interesting.

This document describes the Random Number Generator (RNG) design used in the Cryptographic Co-Processor (CCP) 5.0 hardware included in the AMD RYZEN and EPYC processors.

I cant find much public information about this co-processor other then press releases announcing its existence and that it will have a linux driver. Well we have that driver now.
torvalds/linux

The driver code/comments and git history start to tell us some more useful things, like a list of supported algorithms.

• sha 1/224/256/384/512
• aes 128/192/256
• des3
• rsa

Thats a much shorter list then QAT but early days.
We also have mentions of AMDs Platform Security Processor(PSP), with grammar implying that it is a sub-component of the CCP. The driver also exposes an api for controlling the secure virtualization/encrypted memory feature.

My searching has revealed no openssl engine supporting the CCP, or other support outside of the linux kernel crypto api at thing time. With one exception, freebsd has a vary experimental/broken CCP driver.

 

[mstone]

I think the CCP is more about primitives for a trusted base than crypto offload.

 

[Glasspelican]

I could have made this more clear, i guess thats what i get for doing my writeup at 3am.
The CCP driver is connecting into the linux cryptographic system via an interface intended for hardware accelerators.
Take a look at the Kconfig file that describes the 4 kernel modules in the driver

config CRYPTO_DEV_CCP_DD
    tristate "Secure Processor device driver"
    depends on CPU_SUP_AMD || ARM64
    default m
    help
      Provides AMD Secure Processor device driver.
      If you choose 'M' here, this module will be called ccp.

config CRYPTO_DEV_SP_CCP
    bool "Cryptographic Coprocessor device"
    default y
    depends on CRYPTO_DEV_CCP_DD
    select HW_RANDOM
    select DMA_ENGINE
    select DMADEVICES
    select CRYPTO_SHA1
    select CRYPTO_SHA256
    help
      Provides the support for AMD Cryptographic Coprocessor (CCP) device
      which can be used to offload encryption operations such as SHA, AES
      and more.

config CRYPTO_DEV_CCP_CRYPTO
    tristate "Encryption and hashing offload support"
    default m
    depends on CRYPTO_DEV_CCP_DD
    depends on CRYPTO_DEV_SP_CCP
    select CRYPTO_HASH
    select CRYPTO_BLKCIPHER
    select CRYPTO_AUTHENC
    select CRYPTO_RSA
    help
      Support for using the cryptographic API with the AMD Cryptographic
      Coprocessor. This module supports offload of SHA and AES algorithms.
      If you choose 'M' here, this module will be called ccp_crypto.

config CRYPTO_DEV_SP_PSP
    bool "Platform Security Processor (PSP) device"
    default y
    depends on CRYPTO_DEV_CCP_DD && X86_64
    help
     Provide support for the AMD Platform Security Processor (PSP).
     The PSP is a dedicated processor that provides support for key
     management commands in Secure Encrypted Virtualization (SEV) mode,
     along with software-based Trusted Execution Environment (TEE) to
enable third-party trusted applications.

The help sections for these modules describe both cryptographic acceleration provided by CRYPTO_DEV_CCP_CRYPTO and trusted base provided by CRYPTO_DEV_SP_PSP

 

[mstone]

"you can do it" is not the same as "it's worth doing".

 

[Glasspelican]

I took my NAS offline to do some testing, its not a ryzen cpu its one of the am4 socket excavator apus (a8-9600). The system has a fully updated bios, i was booting Ubuntu 18.04.1 with kernel 4.15 and ubuntu's 4.19-rc3. The results are the same for both kernels. The CCP driver did not auto-load at boot but could be manually loaded, and the CCP-CRYPTO driver refused to load.

I also borrowed a friends gaming pc for a few hours. This PC was running a Ryzen r3 1300. Running the same test as above the CCP driver auto-loaded at startup, and the CCP_CRYPTO driver did not auto-load but could be manually loaded.
With the crypto driver loaded I installed the Cryptodev-linux module driver to expose linuxs cryptographic api to userspace programs, and rebuilt gnuTLS with cryptodev support enabled.
With this setup gnuTLS showed the exact same performance across all algorithms, with the exception of a small performance regression in the NULL cypher. I ran out of time with the borrowed machine before i could repeat the tests with openssl, but i have no reason to beleave they would be any different as it appears that no crypto offload is happening.

TLDR: I could not get crypto offload working on the systems i have for testing.

Based on the above i see three possibilities.

1. The one test system is running an (older) bios version with ccp firmware that does not expose ccp-crypto
2. ccp-crypto is not enabled on all SKUs, perhaps as a means to differentiate the upcoming Ryzen PRO line
3. I did something wrong

 

[its]

Don’t expect high performance.
D12723 Add ccp(4): experimental driver for AMD Crypto Co-Processor