Re: [dpdk-dev] [RFC] cryptodev/sym: GCM IV len != 12 byte case

["Trahe, Fiona" <fiona.trahe@intel.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2745 bytes --]

Hi Arek,

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, March 20, 2019 6:47 PM
> To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; akhil.goyal@nxp.com; ravi1.kumar@amd.com;
> tdu@semihalf.com; lironh@marvell.com; walan@marvell.com
> Subject: [RFC] cryptodev/sym: GCM IV len != 12 byte case
> 
> Hi all,
> 
> There is a proposition to amend a bit API due to the following lines:
> 
> * - For GCM mode, this is either 12 (for 96-bit IVs)
>  * or 16, in which case data points to J0.
> ...
> } iv;   /**< Initialisation vector parameters */
> 
> 
> Problem arise when driver cannot support J0 input, right now we know that OPENSSL PMD works with IV
> instead of J0 when iv_len != 12.
> So it may be that we have to somehow support both. There are two options, and I am very curious about
> community opinion.
> 
> 1) Add a flag to aead_xform.iv to supports IV or J0 like this:
> uint8_t IV_used;
> And this could be reflected in capabilities. Of course for 96bits IV this field would not be used, so it would
> had to be set only for iv.length != 12
> 2) Change API comments to something like:
> * - For GCM mode, this is either 12 (for 96-bit IVs),
> * - for IV length different than 96 bits it is or J0 or IV,
> * - refer to specific driver rst or capabilities which one
> * - is supported, etc. (J0 by definition is of 16 bytes len)
> 
> I cc'ing maintainers of drivers that support iv_len != 12 bytes.
> Cannot check how it works as I have no hw.
> 
> Regards,
> Arek

[Fiona] Pablo suggested a simpler approach. Same functional change in API - i.e. support input in both J0 and IV formats, but different implementation, no need for new flags in session or capabilities. Proposal is to use special value 0 to indicate J0 format, in both capabilities and xform, i.e. 
appl passes in rte_crypto_cipher_xform.iv.length = 0
 => J0 format, already known to be 16bytes, so no need for explicit length info
appl passes in iv.length > 0
 => IV, so PMD must derive J0. (current API, no change here)

Capability example1: PMD can accept a 16-byte J0 OR a 12 byte IV
.iv_size = {
	.min = 0,
	.max = 12,
	.increment = 12
}
Capability example2: PMD can accept IV of length 12 and 16, but not J0.  
.iv_size = {
	.min = 12,
	.max = 16,
	.increment = 4
}
Capability example3: PMD can accept IV of length between 8 and 128, but not J0.  
.iv_size = {
	.min = 8,
	.max = 128,
	.increment = 1
}
Capability example4: PMD can accept IV of length between 1 and 128, and also J0.  
.iv_size = {
	.min = 0,
	.max = 128,
	.increment = 1
}
What do you think?