Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher block sizes

[Matan Azrad <matan@nvidia.com>]

From: Anoob Joseph
> Hi Matan,
> 
> With the current spec, AES-XTS operation offloading would mean application is
> expected to track data blocks and the corresponding tweak & cipher stealing,
> while the final crypto operation gets offloaded to PMD. This proposal aims at
> moving the entire AES-XTS operation (including tweak update) to PMD. Did I
> understand the proposal right?

Yes, we want to define well what is the "data-unit" size from AES-XTS standard per session (or operation), then, to allow to the PMD users to send multiple data-units in one operation.
The initial tweak(for the first data-unit) will be set by the user in the operation, and according the standard(probably what you call "spec") the rest data-units tweak values should  be assigned consecutively, so this part will be done by the PMD\device in multiple data-units case. 

> 
> If yes, I believe this is a good feature to be added. But I've few questions,
> 
> 1. Who is responsible for cipher stealing? Do we expect PMD to pad the final
> data unit?

Sure, this is the offload, no? to support what the algorithm defines.

> 2. If we treat AES-XTS as an operation for just encrypting and decrypting a large
> blob of data, the current proposal would be good enough. But often, AES-XTS is
> used in disk encryption where selected pages are updated without requiring the
> entire disk to be decrypted (& encrypted after). Did you consider if we could
> extend the spec to support such a use case also? (Agreed that we could do page
> updates by handling tweak etc from application as is being done now).

Sure,
For any amount of consecutive data-units, the user can do encrypt\decrypt in one operation: 1, 2, all the disk..... in one mbuf or chain of mbufs...
But the blob of data must be multiple of the session data-unit size parameter that I want to define now in the session API(\ transformation).

> 3. On top level, this requirement has similarities to rte_security. Did you
> consider that route?

No, but why do you care? The regular crypto API should support it too, it is basic...


> Thanks,
> Anoob

Thank you.
 
> > -----Original Message-----
> > From: Matan Azrad <matan@nvidia.com>
> > Sent: Thursday, February 4, 2021 8:04 PM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Declan Doherty <declan.doherty@intel.com>;
> > Somalapuram Amaranath <asomalap@amd.com>; Ruifeng Wang
> > <ruifeng.wang@arm.com>; Ajit Khaparde <ajit.khaparde@broadcom.com>;
> > Anoob Joseph <anoobj@marvell.com>; Fan Zhang
> > <roy.fan.zhang@intel.com>; John Griffin <john.griffin@intel.com>;
> > Pablo de Lara <pablo.de.lara.guarch@intel.com>; Michael Shamis
> > <michaelsh@marvell.com>; Nagadheeraj Rottela
> > <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> > Gagandeep Singh <g.singh@nxp.com>; Jay Zhou <jianjay.zhou@huawei.com>
> > Subject: [EXT] [PATCH] cryptodev: support multiple cipher block sizes
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > In cryptography, a block cipher is a deterministic algorithm operating
> > on fixed-length groups of bits, called blocks.
> >
> > A block cipher consists of two paired algorithms, one for encryption
> > and the other for decryption. Both algorithms accept two inputs:
> > an input block of size n bits and a key of size k bits; and both yield
> > an n-bit output block. The decryption algorithm is defined to be the
> > inverse function of the encryption.
> >
> > Some cipher algorithms support multiple block sizes, e.g. AES-XTS
> > supports any block size in range [16B, 2^24B], in this case, A
> > plain-text data, divided into N amount of n-bits blocks, which is
> > encrypted to the same data size, cipher-text, must be decrypted in the
> > same division of N amount of n-bits blocks in order to get the same plain-text
> data.
> >
> > The current cryptodev API doesn't allow the user to select a specific
> > block size supported by the devices In addition, there is no
> > definition how the IV is detected per block when single operation includes
> more than one block.
> >
> > That causes applications to use single operation per block even though
> > all the data is continuous in memory what reduces datapath performance.
> >
> > Add a new feature flag to support multiple block sizes, called
> > RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS.
> > Add a new field in cipher capability, called bsf - block size flags,
> > where the devices can report the range of the supported block sizes.
> > Add a new cipher transformation field, called block_size, where the
> > user can select one block size from the supported range.
> >
> > All the new fields do not change the size of their structures.
> >
> > Using flags to report the supported block sizes capability allows the
> > devices to report a range simply as same as the user to read it simply.
> > Also, thus sizes are usually common and probably will be shared
> > between the devices.
> >
> > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h | 12 ++++++++++++
> > lib/librte_cryptodev/rte_cryptodev.h  | 23 ++++++++++++++++++++++-
> >  2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index 9d572ec..9a1215d 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -265,6 +265,18 @@ struct rte_crypto_cipher_xform {
> >                * which can be in the range 7 to 13 inclusive.
> >                */
> >       } iv;   /**< Initialisation vector parameters */
> > +
> > +     uint32_t block_size;
> > +     /**< When RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS is
> > reported, this is
> > +      * the block size of the algorithm, otherwise or when the value is 0,
> > +      * use the default block size provided in the capability.
> > +      * The value should be in the range defined by the bsf field in the
> > +      * cipher capability.
> > +      *
> > +      * - For AES-XTS it is the size of data-unit, from IEEE Std 1619-2007.
> > +      * For-each data-unit in the operation, the tweak(IV) value is
> > +      * assigned consecutively starting from the operation assigned
> > tweak.
> > +      */
> >  };
> >
> >  /** Symmetric Authentication / Hash Algorithms diff --git
> > a/lib/librte_cryptodev/rte_cryptodev.h
> > b/lib/librte_cryptodev/rte_cryptodev.h
> > index ae34f33..60ba839 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -96,6 +96,19 @@ struct rte_crypto_param_range {  };
> >
> >  /**
> > + * Crypto device supported block size flags for cipher algorithms
> > + * Each flag represents single or range of supported block sizes  */
> > +#define RTE_CRYPTO_CIPHER_BSF_ALL 0x1
> > +/* All the sizes from the algorithm standard */ #define
> > +RTE_CRYPTO_CIPHER_BSF_512_BYTES 0x2 #define
> > +RTE_CRYPTO_CIPHER_BSF_520_BYTES 0x4 #define
> > +RTE_CRYPTO_CIPHER_BSF_4048_BYTES 0x8 #define
> > +RTE_CRYPTO_CIPHER_BSF_4096_BYTES 0x10 #define
> > +RTE_CRYPTO_CIPHER_BSF_4160_BYTES 0x20 #define
> > +RTE_CRYPTO_CIPHER_BSF_1M_BYTES 0x40
> > +
> > +/**
> >   * Symmetric Crypto Capability
> >   */
> >  struct rte_cryptodev_symmetric_capability { @@ -122,11 +135,19 @@
> > struct rte_cryptodev_symmetric_capability {
> >                       enum rte_crypto_cipher_algorithm algo;
> >                       /**< cipher algorithm */
> >                       uint16_t block_size;
> > -                     /**< algorithm block size */
> > +                     /**<
> > +                      * algorithm block size
> > +                      * For algorithms support more than single block size,
> > +                      * this is the default block size supported by the
> > +                      * driver, all the supported sizes are reflected in the
> > +                      * bsf field.
> > +                      */
> >                       struct rte_crypto_param_range key_size;
> >                       /**< cipher key size range */
> >                       struct rte_crypto_param_range iv_size;
> >                       /**< Initialisation vector data size range */
> > +                     uint32_t bsf;
> > +                     /**< Block size flags */
> >               } cipher;
> >               /**< Symmetric Cipher transform capabilities */
> >               struct {
> > --
> > 1.8.3.1