From patchwork Tue Sep 5 10:06:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Github ODP bot X-Patchwork-Id: 111647 Delivered-To: patch@linaro.org Received: by 10.140.94.166 with SMTP id g35csp2627517qge; Tue, 5 Sep 2017 03:12:35 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4oW+cGxC8/B+vuuTL1cBD5YmEymPjVQjwgvykzAfsOHTHz52kZgUT43a47/j7kkK69amwn X-Received: by 10.200.56.184 with SMTP id f53mr4192249qtc.139.1504606355254; Tue, 05 Sep 2017 03:12:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504606355; cv=none; d=google.com; s=arc-20160816; b=e2Z0rKvfas25dY5075oXyPpresL0NnQ36q0rNybs1xueMjfBCfWnDZ1C26UIsKNaQ/ Xw4kvez4YnQKOzN6JxgPRGIhzGcO/fWlj+1R9rTIiKFnJvChnW7lxUbg5VuiAVF/sbED Qi/i0Xz3llZ0Kuy9RDW8AnzFOCZMnnbGIusCFxjADb7SCwMl+BrplfsccZm6yJIIMObu MzLXrBtWr+MixQAm9sTy8oXJf3qZN723wYEvjNPqPxECiMyvEajgW34Vy+KBYf2zMHF6 mmWfuUyUQZEPAA4jq88QCCdknoVl9mTpPUieO4nq0IABU2/1UpiB/xXWCzqbEkn9JznA B5Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject :content-transfer-encoding:mime-version:github-pr-num:references :in-reply-to:message-id:date:to:from:delivered-to :arc-authentication-results; bh=iFG0FmWAl6uGEGH9PHpWWdOoW3SCG6f5G0xMGEbodII=; b=cz8kopqj6nVRJ9GezxwV4R36TdlVGiyrZO2cRvGG5MtIrkGhxdw3wEhMEqfQLr4muS GD30qixcaAaqYe1l+Bbz8y1dEYgAIZzw/w6uzmYjP1IMCvhoQRiGF3c+F2oVI/aGlOlv 5E0o21UhqHBJeEvFjq0n2CbQRzZuOSbvoIpXmfD789cFuijZCukJ4ZlmpZ6Riji/5prv 3qmzfj3QrLGlCXrkf2A/MEPCsFz3aEnila7x/KK46RJefZe/ZUCrvUPTaAF8xoim1E1H HS0Yc64XzlrB+41uVOV+o3QVbJM25gFeRDFlQN4jF+YHDElMfoNtHm7gx03Qy1Gkp2Sk oDrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yandex.ru Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id w193si33540qka.405.2017.09.05.03.12.35; Tue, 05 Sep 2017 03:12:35 -0700 (PDT) Received-SPF: pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yandex.ru Received: by lists.linaro.org (Postfix, from userid 109) id E90CC6445A; Tue, 5 Sep 2017 10:12:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id 84CCE615DE; Tue, 5 Sep 2017 10:08:59 +0000 (UTC) X-Original-To: lng-odp@lists.linaro.org Delivered-To: lng-odp@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 9E80460EA7; Tue, 5 Sep 2017 10:08:42 +0000 (UTC) Received: from forward103j.mail.yandex.net (forward103j.mail.yandex.net [5.45.198.246]) by lists.linaro.org (Postfix) with ESMTPS id 95D6D60890 for ; Tue, 5 Sep 2017 10:06:32 +0000 (UTC) Received: from mxback12g.mail.yandex.net (mxback12g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:91]) by forward103j.mail.yandex.net (Yandex) with ESMTP id 5287934C0F0B for ; Tue, 5 Sep 2017 13:06:31 +0300 (MSK) Received: from smtp1o.mail.yandex.net (smtp1o.mail.yandex.net [2a02:6b8:0:1a2d::25]) by mxback12g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id BhIEizlTsr-6Vj4bF8S; Tue, 05 Sep 2017 13:06:31 +0300 Received: by smtp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 2IVJzcYjl6-6UeWbY5J; Tue, 05 Sep 2017 13:06:30 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client certificate not present) From: Github ODP bot To: lng-odp@lists.linaro.org Date: Tue, 5 Sep 2017 13:06:24 +0300 Message-Id: <1504605984-27954-2-git-send-email-odpbot@yandex.ru> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1504605984-27954-1-git-send-email-odpbot@yandex.ru> References: <1504605984-27954-1-git-send-email-odpbot@yandex.ru> Github-pr-num: 150 MIME-Version: 1.0 Subject: [lng-odp] [PATCH API-NEXT v4 1/1] doc: userguide: document new packet-oriented crypto operations X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "The OpenDataPlane \(ODP\) List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" From: Bill Fischofer Crypto now offers two complementary sets of cryptographic APIs: the original parameter-driven API and a new packet-oriented API designed to be more flexible and consistent with the protocol-aware APIs introduced as part of IPsec support. Update the ODP User Guide to include these new APIs. Signed-off-by: Bill Fischofer --- /** Email created from pull request 150 (Bill-Fischofer-Linaro:crypto-doc) ** https://github.com/Linaro/odp/pull/150 ** Patch: https://github.com/Linaro/odp/pull/150.patch ** Base sha: 91c0b58fc87ba0431241818758cea94438cd5498 ** Merge commit sha: bc91736c78cded105b471e5b17a99f5f46fd3810 **/ doc/users-guide/users-guide-crypto.adoc | 120 ++++++++++++++++++++++++++++---- 1 file changed, 108 insertions(+), 12 deletions(-) diff --git a/doc/users-guide/users-guide-crypto.adoc b/doc/users-guide/users-guide-crypto.adoc index c18e369b..029f47b1 100644 --- a/doc/users-guide/users-guide-crypto.adoc +++ b/doc/users-guide/users-guide-crypto.adoc @@ -1,8 +1,10 @@ == Cryptographic services -ODP provides APIs to perform cryptographic operations required by various -communication protocols (_e.g.,_ IPsec). ODP cryptographic APIs are session -based. +ODP provides APIs to perform cryptographic operations required by +applications. ODP cryptographic APIs are session based and provide +cryptographic algorithm offload services. ODP also offers cryptographic +protocol offload services for protocols such as IPsec using a different set +of APIs. This section covers the main crypto APIs. ODP provides APIs for following cryptographic services: @@ -11,6 +13,11 @@ ODP provides APIs for following cryptographic services: * Random number generation * Crypto capability inquiries +Ciphering and authentication services are accessible via two complementary +sets of related APIs. The original ODP crypto APIs, and a newer +_packet-oriented_ set of crypto APIs that are designed to be consistent with +the protocol-aware cryptographic services offered by the IPsec API set. + === Crypto Sessions To apply a cryptographic operation to a packet a session must be created. All @@ -29,18 +36,40 @@ Other Session parameters include algorithms, keys, initialization vector (optional), encode or decode, output queue for async mode and output packet pool for allocation of an output packet if required. +The parameters that describe the characteristics of a crypto session are +encoded in the `odp_crypto_session_param_t` struct that is passed to the +`odp_crypto_session_create()` API. A successful call returns an +`odp_crypto_session_t` object that in turn is passed as an input parameter to +crypto operation calls. + +When an application is finished with a crypto session the +`odp_crypto_session_destroy()` API is used to release the resources associated +with an `odp_crypto_session_t`. + === Crypto operations After session creation, a cryptographic operation can be applied to a packet -using the `odp_crypto_operation()` API. Applications may indicate a preference -for synchronous or asynchronous processing in the session's `pref_mode` -parameter. However crypto operations may complete synchronously even if an -asynchronous preference is indicated, and applications must examine the -`posted` output parameter from `odp_crypto_operation()` to determine whether -the operation has completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is -expected. In the case of an async operation, the `posted` output parameter -will be set to true. - +in one of two ways. + +==== Parameter-based Crypto Operations +This is the original ODP support for cryptographic operations. The +`odp_crypto_operation()` API takes an input `odp_crypto_op_param_t` struct +that describes the cryptographic operation to be performed. This struct +contains the session to use as well as the input packet the operation is to be +performed on. The caller may either specify an output packet to receive the +operation results or may request that the ODP implementation allocate a new +packet to receive these results from the output pool associated with the +`odp_crypto_session_t`. If the input packet is also used as the output packet, +then an "in place" operation is requested. + +When using the `odp_crypto_operation()` API. Applications may indicate a +preference for synchronous or asynchronous processing in the session's +`pref_mode` parameter. However crypto operations may complete synchronously +even if an asynchronous preference is indicated, and applications must examine +the `posted` output parameter from `odp_crypto_operation()` to determine +whether the operation has completed or if an `ODP_EVENT_CRYPTO_COMPL` +notification is expected. In the case of an async operation, the `posted` +output parameter will be set to true. The operation arguments specify for each packet the areas that are to be encrypted or decrypted and authenticated. Also, there is an option of overriding @@ -61,6 +90,73 @@ session’s completion queue, which can be accessed directly or via the ODP scheduler. The completion event contains the status of the operation and the result. The application has the responsibility to free the completion event. +Upon receipt of an `ODP_EVENT_CRYPTO_COMPL` event, the +`odp_crypto_compl_result()` API is used to retrieve the +`odp_crypto_op_result_t` associated with the event. This result struct in turn +contains: + +* An indication of the success or failure of the crypto operation +* The user context associated with the event +* The output `odp_packet_t`. +* The `odp_crypto_op_status_t` for the requested cipher operation +* The `odp_crypto_op_status_t` for the requested authentication operation + +==== Packet-based Crypto Operations +To simplify the original cryptographic operation request API, as well as to +be more flexible and consistent with the protocol-aware APIs introduced for +IPsec support, a newer packet-oriented set of cryptographic operation +APIs is also provided. Applications may use either API set, but going forward +it is expected that these newer APIs will be the focus of continued +development. + +Instead of a single `odp_crypto_operation()` API, the packet-based form +provides two APIs: `odp_crypto_op()` is the synchronous form while +`odp_crypto_op_enq()` is the asynchronous form. To check which of these are +supported by the ODP implementation, examine the `sync_mode` and `async_mode` +fields in the `odp_crypto_capability_t` struct returned by the +`odp_crypto_capability()` API. + +Both forms take an input array of packets, an optional output array of packets +to receive the results, and an array of `odp_crypto_packet_op_param_t` structs +that describe the operation to be performed on each input packet. As with the +original APIs, the output array may be the same packets to request in-place +operation, or may be specified as `ODP_PACKET_INVALID` to request that ODP +allocate output packets from the pool associated with the +`odp_crypto_session_t` being used. + +The key differences between the `odp_crypto_op_param_t` used by the original +APIs and the `odp_crypto_packet_op_param_t` used by the new APIs are: + +* The original API takes a single `odp_crypto_op_param_t` since it operates on +a single packet whereas the new forms take an array of +`odp_crypto_packet_op_param_t` structs, one for each input packet. + +* The `odp_crypto_packet_op_param_t` does not contain any packet information +since the input and output packets are supplied as API parameters rather than +being encoded in this struct. + +* The `odp_crypto_packet_op_param_t` does not contain a user context field. + +In addition, the `odp_crypto_session_t` field `op_mode` is used instead of +the `pref_mode` field when the packet-oriented APIs are used. If the +`op_mode` is set to `ODP_CRYPTO_SYNC` then the synchronous form of the API +must be used and if `op_mode` is set to `ODP_CRYPTO_ASYNC` then the +asynchronous form of the API must be used. It is an error to attempt to use +a form of the API not properly matched to the mode of the crypto session. + +The output of a packet-based crypto operation is an `odp_packet_t` (one for +each input packet) that is returned either synchronously or +asynchronously. Asynchronous return is in the form of `ODP_EVENT_PACKET` +events that have event subtype `ODP_EVENT_PACKET_CRYPTO`. The packet +associated with such events is obtained via the +`odp_crypto_packet_from_event()` API. The `odp_crypto_result()` API, in turn, +retrieves the `odp_crypto_packet_result_t` from this `odp_packet_t` that +contains: + +* An indication of whether the crypto packet operation was successful or not +* The `odp_crypto_op_status_t` for the requested cipher operation +* The `odp_crypto_op_status_t` for the requested authentication operation + === Random number Generation ODP provides two APIs to generate various kinds of random data bytes. Random