Example 1 (corresponds to row F in the table below):¶

Memory signature domain is not configured, and memory data is encrypted.

Wire signature domain is not configured, and wire data is in plaintext.

encrypt_on_tx is set to false, and because signature is not configured, signature_crypto_order value doesn’t matter.

A SEND is issued using the MKey as a local key.

Result: device will gather the encrypted data from the MKey (using whatever layout configured to the MKey to locate the actual memory), decrypt it using the supplied DEK and transmit the decrypted data to the wire.

Example 1.1:¶

Same as above, but a RECV is issued with the same MKey, and RX happens.

Result: device will receive the data from the wire, encrypt it using the supplied DEK and scatter it to the MKey (using whatever layout configured to the MKey to locate the actual memory).

Example 2 (corresponds to row C in the table below):¶

Memory signature domain is configured for no signature, and memory data is in plaintext.

Wire signature domain is configured for T10DIF every 512 Bytes block, and wire data (including the T10DIF) is encrypted.

encrypt_on_tx is set to true and signature_crypto_order is set to be MLX5DV_SIGNATURE_CRYPTO_ORDER_SIGNATURE_BEFORE_CRYPTO_ON_TX. data_unit_size is set to MLX5DV_BLOCK_SIZE_520.

The MKey is sent to a remote node that issues a RDMA_READ to this MKey.

Result: device will gather the data from the MKey (using whatever layout configured to the MKey to locate the actual memory), generate an additional T10DIF field every 512B of data, encrypt the data and the newly generated T10DIF field using the supplied DEK, and transmit it to the wire.

Example 2.1:¶

Same as above, but remote node issues a RDMA_WRITE to this MKey.

Result: device will receive the data from the wire, decrypt the data using the supplied DEK, validate each T10DIF field against the previous 512B of data, strip the T10DIF field, and scatter the data alone to the MKey (using whatever layout configured to the MKey to locate the actual memory).

Crypto Attributes¶

Crypto attributes describe the format (encrypted or plaintext) and layout of the input and output data in memory and wire domains, the crypto standard that should be used and its attributes.

struct mlx5dv_crypto_attr {


    enum mlx5dv_crypto_standard crypto_standard;


    bool encrypt_on_tx;


    enum mlx5dv_signature_crypto_order signature_crypto_order;


    enum mlx5dv_block_size data_unit_size;


    char initial_tweak[16];


    struct mlx5dv_dek *dek;


    char keytag[8];


    uint64_t comp_mask;
};
    

crypto_standard

The encryption standard that should be used, currently can only be the following value

encrypt_on_tx

If set, memory data will be encrypted during TX and wire data will be decrypted during RX. If not set, memory data will be decrypted during TX and wire data will be encrypted during RX.

signature_crypto_order

Controls the order between crypto and signature operations (Please see detailed table below). Relevant only if signature is configured. Can be one of the following values

data_unit_size

For storage, this will normally be the storage block size. The tweak is incremented after each data_unit_size during the encryption. can be one of enum mlx5dv_block_size.

initial_tweak

A value to be used during encryption of each data unit. Must be supplied in little endian. This value is incremented by the device for every data unit in the message. For storage encryption, this will normally be the LBA of the first block in the message, so that the increments represent the LBAs of the rest of the blocks in the message.

dek

The DEK to be used for the crypto operations. This DEK must be pre-loaded to the device using mlx5dv_dek_create().

key_tag

A tag that verifies that the correct DEK is being used. key_tag is optional and is valid only if the DEK was created with has_keytag set to true. If so, it must match the key tag that was provided when the DEK was created. Supllied in plaintext.

comp_mask

Reserved for future extension, must be 0 now.