Hi Robbie, if I understand correctly your proposal hash_result_offset would be used for "encode" sessions , hash_verify_ptr for "decode" sessions. I would make the following comment : while hash_result_offset clearly indicates that the ICV is written in the output frame (or input, in case of in place), hash_verify_ptr is a bit ambiguous - some hints about where that pointer is (e.g. in a DMA-able area) would be useful for the implementation to avoid the copy. It's pretty similar with override_iv_ptr on decryption which in fact points in the frame on the ESP IV - are there applications for which this may not be true? This was an example of what I meant by using protocol awareness for performance improvements. Related to "combined" session, I meant both non-NULL cipher and authentication. I noticed that odp_ipsec uses "combined" sessions to decode frames which have only one IPsec header (AH or ESP). This may pose problems to some HW or implementations - in my case now it does.
Alex On 25 August 2014 16:54, Robbie King (robking) <[email protected]> wrote: > Hi Alex, > > > > Sorry just getting back to you. I was thinking about the ICV thing some > more this > > AM. Currently we’re using the “hash_result_offset” as both an input and > output > > variable. What if we have “hash_result_offset” be the offset at which the > > implementation stores the computed ICV value, and have a new variable > > “hash_verify_ptr” that is a memory pointer to the value to be compared > against > > when doing the verify operation? > > > > This way the implementation has more freedom as to how to accomplish the > > verification of the ICV. > > > > On your second question, I’m not sure I understand what you mean by > “combined > > session”? > > > > *From:* Alexandru Badicioiu [mailto:[email protected]] > *Sent:* Wednesday, August 20, 2014 10:51 AM > *To:* Robbie King (robking) > *Cc:* Taras Kondratiuk; lng-odp-forward ([email protected]); Bala > Manoharan > *Subject:* Re: Clarification of ICV handling in linux-generic crypto... > > > > Hi Robbie, > > I noticed myself that the application takes care of zeroing mutable fields > in the IP header but it does not do the same thing with the AH ICV, leaving > this task to the implementation. While ODP crypto API wanted to be protocol > agnostic, the current (linux-generic) implementation is not. This made me > wondering how much of protocol aware an implementation can be or could we > make use of protocol awareness for performance improvement, for example. > > Max's proposal indeed removes this protocol awareness from the > implementation, but is not optimal from the performance point of view; > placing the ICV somewhere else is not either. > > For crypto engines which can handle in/out S/G lists (my case) an input > S/G list for ICV computation can be used instead of the contiguous auth > range having as zeroized ICV a fixed buffer provided by the implementation. > > Another question related to the application - I noticed it attempts to use > combined sessions for decoding single protocol input packets (AH or ESP) - > is the HW always capable of dealing with this? > > > > Thanks, > > Alex > > > > > > > > > > On 20 August 2014 17:05, Robbie King (robking) <[email protected]> wrote: > > Hi Alex, again my apologies to all for dropping the ball on this. > > > > I had clarified with Max how CDAL expects the ICV to be handled. That is > not to > > say that ODP crypto has to behave this way, but it can hopefully > facilitate emulating > > the desired CDAL behavior. Here is Max’s clarification with some > rewording to > > reflect ODP crypto API terminology. > > > > 1) In encryption direction, “hash_result_offset” is the location where the > computed > > ICV will be placed. The buffer range from “auth_range” is used for the > computation of > > the ICV. Any preparation for the buffer (e.g. in the case AH, the ICV > location in the header > > needs to be zeroed out) is the responsibility of the caller. > > 2) In decryption direction, “hash_result_offset” is the location where the > packet ICV is > > located and the computed ICV needs to be compared with it. The buffer > range from “auth_range” > > is used for the computation of the ICV. Any preparation for the buffer > (e.g. in the case AH, the > > ICV location in the header needs to be zeroed out) is the responsibility > of the caller. Also, please > > note that, for AH case, the caller needs to relocate the packet ICV from > AH header to a location > > not inside the “auth_range”. > > > > So Max’s proposal puts the burden of zero’ing the ICV in the > authentication (#2) direction > > on the application, not the implementation (implementation does it today). > > > > For me the big question is, how do we handle “hash_result_offset” if it is > by design not > > inside the packet for authentication? Does the application grow the > packet by 12 bytes > > and place the original ICV value at the end of the packet, then trim it > back off post > > MD5 generation? > > > > Thanks, > > Robbie > > > > > > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
