From sacadmin Tue Feb 13 14:25:16 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DMPGqO011700; Tue, 13 Feb 2007 14:25:16 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1DMP5SO349275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 14:25:05 -0800 (PST) Received: (from darrenm@localhost) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id l1DMP57q349271; Tue, 13 Feb 2007 14:25:05 -0800 (PST) Date: Tue, 13 Feb 2007 14:25:05 -0800 (PST) From: Darren J Moffat Message-Id: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> To: PSARC@sac.sfbay.sun.com Cc: crypto-discuss@opensolaris.org Subject: Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] Status: RO Content-Length: 6800 Subject: PSARC FastTrack [02/20/2007]: Crypto Context sharing between providers Template Version: @(#)sac_nextcase %I% %G% SMI 1. Introduction 1.1. Project/Component Working Name: Crypto Context sharing between providers 1.2. Name of Document Author/Supplier: Author: Krishna Yenduri 1.3 Date of This Document: 13 February, 2007 4. Technical Description Title: Crypto Context sharing between providers 1. Overview This document describes changes to the Solaris Kernel Cryptographic SPI to support operation context sharing for improved performance. The Interface taxonomy is Consolidation Private. The Release taxonomy is Patch/Micro. Diff-marked draft manpages, and header files are included in the case directory. 2. Problem Many ciphers are faster to do in software for small data sizes. Doing them in hardware degrades performance instead of helping. Currently, the Solaris kernel crypto framework (kCF) checks that the input data size for a crypto operation is above a certain mechanism specific threshold before it will use a hardware provider. This check is possible only for atomic kernel API like crypto_encrypt() that do not keep any context across calls. But, there are many applications which do multi-part requests that require that context be kept across calls. Also, stream ciphers like RC4 are usable only with multi-part API in SSL. Currently, these applications that do multi-part API suffer from degraded performance for smaller data sizes as they will always use the hardware provider for each part of the multi-part API. So, there is a need to address this problem. 3. Solution The basic idea of the solution is to share the operation context between a hardware provider and a software provider and use the software provider for small data sizes and use the hardware provider otherwise. Note that a hardware provider may not be able share its operation context if the key object does not allow it. So, the solution is limited to cases where it is possible to do so. Initially, we considered using the existing PKCS #11 API C_GetOperationState/C_SetOperationState for this purpose. But, these API add overhead for each part of the multi-part API. Also, they are not intended to be usable across multiple providers. So, we extended the existing service provider interface (SPI) to enable the sharing of the operation context with little overhead. We discuss the details below. 3.3 SPI changes 3.3.1. cm_mech_flags field A provider that can support sharing of context needs to set CRYPTO_CAN_SHARE_OPSTATE bit flag in the cm_mech_flags field of crypto_mech_info_t structure. The existing field, cm_keysize_unit, in the crypto_mech_info_t structure is an uint32_t and it currently has only two bit flags defined. We rename this field to cm_mech_flags and maintain cm_keysize_unit as an alias for cm_mech_flags so that older providers continue to compile. The advantage with using an existing field rather than adding a new field is that we avoid having two versions of this structure that will add unnecessary complexity to kCF to maintain binary compatibility for older providers. 3.3.2. Format of the shared context The mechanism specific context that is shared between kCF and the provider is part of the SPI. Initially, we define the context for only the RC4 mechanism. typedef struct { uchar_t arr[256]; uchar_t i, j; uint64_t pad; /* For 64-bit alignment */ } arcfour_state_t; We will be adding definitions for other bulk ciphers as needed. 3.3.3. Changes to crypto_ctx_t structure Two new fields are added to crypto_ctx_t structure + uint32_t cc_flags; /* flags */ + void *cc_opstate; /* state */ } crypto_ctx_t; + /* Values for cc_flags field */ + #define CRYPTO_INIT_OPSTATE 0x00000001 /* allocate and init cc_opstate */ + #define CRYPTO_USE_OPSTATE 0x00000002 /* .. start using it as context */ + The new fields are added to the end of the crypto_ctx_t structure. So, a old provider continues to work. Note that a provider should never need to allocate this structure since it is allocated by kCF and is passed to the provider. 3.3.4. Provider responsibilities A provider that sets CRYPTO_CAN_SHARE_OPSTATE flag needs to check the cc_flags field of crypto_ctx_t argument a. if routine is init entry point (e.g. encrypt_init()) check for CRYPTO_INIT_OPSTATE flag. If flag is set and the configuration/key material permits sharing . allocate the mechanism specific context defined by kCF . Initialize the mechanism specific context . set CRYPTO_USE_OPSTATE flag in cc_flags field . set cc_opstate field to the context A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE flag. For example, a provider needs to do this if the key can not leave the hardware keystore. In this case, it should leave cc_opstate field alone. b. if routine is update entry point (e.g. encrypt_update()) check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism specific context pointed to by cc_opstate c. A provider frees up cc_opstate at the same time it frees up cc_framework_private. So, a provider is in charge of both allocation and freeing cc_opstate. 3.3.5. Changes to existing providers KCF providers in ON consolidation are modified to use the updated interfaces. These include the software provider, arcfour, and the hardware provider, n2cp. 4. Bug/RFE Number(s): 6494834 5. Exported Interfaces: +--------------------------------+---------------------------+--------------+ | Interface | Classification | Comments | +--------------------------------+---------------------------+--------------+ | crypto_mech_info_t | Consolidation | structure | | | Private | | | | | | | crypto_ctx_t | | structure | | | | | | arcfour_state_t | | structure | | | | | | | | | | spi.h | | include files | | common.h | | | | | | | +--------------------------------+---------------------------+--------------+ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Tue Feb 13 14:39:52 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DMdqUX012058 for ; Tue, 13 Feb 2007 14:39:52 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1DMdpdo015294 for ; Tue, 13 Feb 2007 14:39:51 -0800 (PST) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1DMdpoa000034 for ; Tue, 13 Feb 2007 15:39:51 -0700 (MST) Received: from mms2aes.sun.com ([150.143.232.24] [150.143.232.24]) by relay24.sun.com with ESMTP; Tue, 13 Feb 2007 22:39:50 Z Received: from mms25bas.mms.us.syntegra.com (mms25bas.mms.us.syntegra.com [192.12.251.90]) by mms2aes.sun.com with ESMTP id BT-MMP-2064272; Tue, 13 Feb 2007 22:39:50 Z Received: from mail.tadpolecomputer.co.uk ([82.111.17.14] [82.111.17.14]) by relay21.sun.com with ESMTP; Tue, 13 Feb 2007 22:39:50 Z Received: from zippy.garrett ([192.168.251.21]) by mail.tadpolecomputer.co.uk with esmtp (Exim 4.66) (envelope-from ) id 1HH6JQ-0004DN-LP; Tue, 13 Feb 2007 22:39:49 +0000 Message-Id: <45D23E30.70807@tadpole.com> Date: Tue, 13 Feb 2007 14:39:44 -0800 From: "Garrett D'Amore" User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Darren J Moffat CC: PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> In-Reply-To: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 8389 Hmmm... for most of the hardware crypto engines I've seen, the context is not necessarily portable. (I.e. it doesn't conform to any standard layout, and the details might not be documented.) RC4 is somewhat unique in this regard, in that the context for RC4 is fairly trivial. But RC4 is one of those algorithms where an optimized CPU version of the algorithm is almost always a better choice. (I.e. the cost of DMA setup, etc. usually outweighs any miniscule benefit of RC4 acceleration. Additionally, the cost of copying the data is often close to the cost of doing the algorithm "in place" in the CPU.) Do we really expect this to have value outside of RC4? AES would be a good example, I think. I've not looked yet at the AES engines that are commonly available, but I wouldn't be surprised if the "state" for those engines is really pretty much just a black box. -- Garrett Darren J Moffat wrote: > Subject: PSARC FastTrack [02/20/2007]: Crypto Context sharing between providers > > > Template Version: @(#)sac_nextcase %I% %G% SMI > 1. Introduction > 1.1. Project/Component Working Name: > Crypto Context sharing between providers > 1.2. Name of Document Author/Supplier: > Author: Krishna Yenduri > 1.3 Date of This Document: > 13 February, 2007 > 4. Technical Description > > Title: Crypto Context sharing between providers > > 1. Overview > > This document describes changes to the Solaris Kernel Cryptographic > SPI to support operation context sharing for improved performance. > > The Interface taxonomy is Consolidation Private. > The Release taxonomy is Patch/Micro. > > Diff-marked draft manpages, and header files are included > in the case directory. > > 2. Problem > > Many ciphers are faster to do in software for small data sizes. Doing them in > hardware degrades performance instead of helping. Currently, the Solaris > kernel crypto framework (kCF) checks that the input data size for a > crypto operation is above a certain mechanism specific threshold before > it will use a hardware provider. This check is possible only for > atomic kernel API like crypto_encrypt() that do not keep any context across > calls. But, there are many applications which do multi-part requests that > require that context be kept across calls. Also, stream ciphers like RC4 > are usable only with multi-part API in SSL. > > Currently, these applications that do multi-part API suffer from degraded > performance for smaller data sizes as they will always use the hardware > provider for each part of the multi-part API. So, there is a need > to address this problem. > > > 3. Solution > > The basic idea of the solution is to share the operation context between > a hardware provider and a software provider and use the software provider > for small data sizes and use the hardware provider otherwise. Note that > a hardware provider may not be able share its operation context if the > key object does not allow it. So, the solution is limited to cases where it > is possible to do so. > > Initially, we considered using the existing PKCS #11 API > C_GetOperationState/C_SetOperationState for this purpose. But, these API > add overhead for each part of the multi-part API. Also, they are not intended > to be usable across multiple providers. So, we extended the existing service > provider interface (SPI) to enable the sharing of the operation context > with little overhead. We discuss the details below. > > > 3.3 SPI changes > > 3.3.1. cm_mech_flags field > > A provider that can support sharing of context needs to set > CRYPTO_CAN_SHARE_OPSTATE bit flag in the cm_mech_flags field of > crypto_mech_info_t structure. > > The existing field, cm_keysize_unit, in the crypto_mech_info_t structure > is an uint32_t and it currently has only two bit flags defined. We rename > this field to cm_mech_flags and maintain cm_keysize_unit as an alias for > cm_mech_flags so that older providers continue to compile. > > The advantage with using an existing field rather than adding a new field is that > we avoid having two versions of this structure that will add unnecessary complexity > to kCF to maintain binary compatibility for older providers. > > > 3.3.2. Format of the shared context > > The mechanism specific context that is shared between kCF and the provider > is part of the SPI. Initially, we define the context for only the RC4 mechanism. > > typedef struct { > uchar_t arr[256]; > uchar_t i, j; > uint64_t pad; /* For 64-bit alignment */ > } arcfour_state_t; > > We will be adding definitions for other bulk ciphers as needed. > > > 3.3.3. Changes to crypto_ctx_t structure > > Two new fields are added to crypto_ctx_t structure > + uint32_t cc_flags; /* flags */ > + void *cc_opstate; /* state */ > } crypto_ctx_t; > > + /* Values for cc_flags field */ > + #define CRYPTO_INIT_OPSTATE 0x00000001 /* allocate and init cc_opstate */ > + #define CRYPTO_USE_OPSTATE 0x00000002 /* .. start using it as context */ > + > > The new fields are added to the end of the crypto_ctx_t structure. So, a > old provider continues to work. Note that a provider should never need to > allocate this structure since it is allocated by kCF and is passed to > the provider. > > 3.3.4. Provider responsibilities > > A provider that sets CRYPTO_CAN_SHARE_OPSTATE flag needs to check > the cc_flags field of crypto_ctx_t argument > > a. if routine is init entry point (e.g. encrypt_init()) > > check for CRYPTO_INIT_OPSTATE flag. If flag is set and the > configuration/key material permits sharing > . allocate the mechanism specific context defined by kCF > . Initialize the mechanism specific context > . set CRYPTO_USE_OPSTATE flag in cc_flags field > . set cc_opstate field to the context > > A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE flag. > For example, a provider needs to do this if the key can not leave the > hardware keystore. In this case, it should leave cc_opstate field alone. > > b. if routine is update entry point (e.g. encrypt_update()) > > check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism > specific context pointed to by cc_opstate > > c. A provider frees up cc_opstate at the same time it frees up > cc_framework_private. So, a provider is in charge of both allocation > and freeing cc_opstate. > > > 3.3.5. Changes to existing providers > > KCF providers in ON consolidation are modified to use the > updated interfaces. These include the software provider, arcfour, > and the hardware provider, n2cp. > > > 4. Bug/RFE Number(s): 6494834 > > 5. Exported Interfaces: > > +--------------------------------+---------------------------+--------------+ > | Interface | Classification | Comments | > +--------------------------------+---------------------------+--------------+ > | crypto_mech_info_t | Consolidation | structure | > | | Private | | > | | | | > | crypto_ctx_t | | structure | > | | | | > | arcfour_state_t | | structure | > | | | | > | | | | > | spi.h | | include files | > | common.h | | | > | | | | > +--------------------------------+---------------------------+--------------+ > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > _______________________________________________ > crypto-discuss mailing list > crypto-discuss@opensolaris.org > http://opensolaris.org/mailman/listinfo/crypto-discuss > -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 From sacadmin Tue Feb 13 15:28:26 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DNSQ3s012852 for ; Tue, 13 Feb 2007 15:28:26 -0800 (PST) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1DNSQIs007301 for ; Tue, 13 Feb 2007 15:28:26 -0800 (PST) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1DNSLEC017910 for ; Tue, 13 Feb 2007 15:28:21 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDF00E01D4QZE00@d1-sfbay-10.sun.com> (original mail from Misaki.Kataoka@Sun.COM) for PSARC@sac.sfbay.Sun.COM; Tue, 13 Feb 2007 15:28:21 -0800 (PST) Received: from sun.com ([129.150.24.43]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDF008N4D77S2Y0@d1-sfbay-10.sun.com>; Tue, 13 Feb 2007 15:28:21 -0800 (PST) Date: Tue, 13 Feb 2007 15:28:19 -0800 From: Misaki Kataoka Subject: Re: [crypto-discuss] Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] In-reply-to: <45D23E30.70807@tadpole.com> Sender: Misaki.Kataoka@Sun.COM To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Message-id: <45D24993.5020005@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_m7cSMnDXXbzPzAgHovZ/0Q)" X-Accept-Language: ja References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> <45D23E30.70807@tadpole.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20040406 Status: RO Content-Length: 18131 This is a multi-part message in MIME format. --Boundary_(ID_m7cSMnDXXbzPzAgHovZ/0Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Garrett, I can only speak for SCA6000 and N2CP, but if the key is not sensitive, the context sharing is possible for AES also. The context may look something like: typedef struct { uchar_t keyval[16]; uchar_t iv[16]; uchar_t unprocessed_data[16]; uint32_t unprocessed_data_len; } aes_state_t; SW cannot take advantage of the pre-calcurated key shedules, but it may still be faster to process a job in SW in some cases. -- misaki Garrett D'Amore wrote: >Hmmm... for most of the hardware crypto engines I've seen, the context >is not necessarily portable. (I.e. it doesn't conform to any standard >layout, and the details might not be documented.) > >RC4 is somewhat unique in this regard, in that the context for RC4 is >fairly trivial. But RC4 is one of those algorithms where an optimized >CPU version of the algorithm is almost always a better choice. (I.e. >the cost of DMA setup, etc. usually outweighs any miniscule benefit of >RC4 acceleration. Additionally, the cost of copying the data is often >close to the cost of doing the algorithm "in place" in the CPU.) > >Do we really expect this to have value outside of RC4? AES would be a >good example, I think. I've not looked yet at the AES engines that are >commonly available, but I wouldn't be surprised if the "state" for those >engines is really pretty much just a black box. > > -- Garrett > >Darren J Moffat wrote: > > >>Subject: PSARC FastTrack [02/20/2007]: Crypto Context sharing between providers >> >> >>Template Version: @(#)sac_nextcase %I% %G% SMI >>1. Introduction >> 1.1. Project/Component Working Name: >> Crypto Context sharing between providers >> 1.2. Name of Document Author/Supplier: >> Author: Krishna Yenduri >> 1.3 Date of This Document: >> 13 February, 2007 >>4. Technical Description >> >>Title: Crypto Context sharing between providers >> >>1. Overview >> >>This document describes changes to the Solaris Kernel Cryptographic >>SPI to support operation context sharing for improved performance. >> >>The Interface taxonomy is Consolidation Private. >>The Release taxonomy is Patch/Micro. >> >>Diff-marked draft manpages, and header files are included >>in the case directory. >> >>2. Problem >> >>Many ciphers are faster to do in software for small data sizes. Doing them in >>hardware degrades performance instead of helping. Currently, the Solaris >>kernel crypto framework (kCF) checks that the input data size for a >>crypto operation is above a certain mechanism specific threshold before >>it will use a hardware provider. This check is possible only for >>atomic kernel API like crypto_encrypt() that do not keep any context across >>calls. But, there are many applications which do multi-part requests that >>require that context be kept across calls. Also, stream ciphers like RC4 >>are usable only with multi-part API in SSL. >> >>Currently, these applications that do multi-part API suffer from degraded >>performance for smaller data sizes as they will always use the hardware >>provider for each part of the multi-part API. So, there is a need >>to address this problem. >> >> >>3. Solution >> >>The basic idea of the solution is to share the operation context between >>a hardware provider and a software provider and use the software provider >>for small data sizes and use the hardware provider otherwise. Note that >>a hardware provider may not be able share its operation context if the >>key object does not allow it. So, the solution is limited to cases where it >>is possible to do so. >> >>Initially, we considered using the existing PKCS #11 API >>C_GetOperationState/C_SetOperationState for this purpose. But, these API >>add overhead for each part of the multi-part API. Also, they are not intended >>to be usable across multiple providers. So, we extended the existing service >>provider interface (SPI) to enable the sharing of the operation context >>with little overhead. We discuss the details below. >> >> >>3.3 SPI changes >> >>3.3.1. cm_mech_flags field >> >>A provider that can support sharing of context needs to set >>CRYPTO_CAN_SHARE_OPSTATE bit flag in the cm_mech_flags field of >>crypto_mech_info_t structure. >> >>The existing field, cm_keysize_unit, in the crypto_mech_info_t structure >>is an uint32_t and it currently has only two bit flags defined. We rename >>this field to cm_mech_flags and maintain cm_keysize_unit as an alias for >>cm_mech_flags so that older providers continue to compile. >> >>The advantage with using an existing field rather than adding a new field is that >>we avoid having two versions of this structure that will add unnecessary complexity >>to kCF to maintain binary compatibility for older providers. >> >> >>3.3.2. Format of the shared context >> >>The mechanism specific context that is shared between kCF and the provider >>is part of the SPI. Initially, we define the context for only the RC4 mechanism. >> >>typedef struct { >> uchar_t arr[256]; >> uchar_t i, j; >> uint64_t pad; /* For 64-bit alignment */ >>} arcfour_state_t; >> >>We will be adding definitions for other bulk ciphers as needed. >> >> >>3.3.3. Changes to crypto_ctx_t structure >> >>Two new fields are added to crypto_ctx_t structure >>+ uint32_t cc_flags; /* flags */ >>+ void *cc_opstate; /* state */ >> } crypto_ctx_t; >> >>+ /* Values for cc_flags field */ >>+ #define CRYPTO_INIT_OPSTATE 0x00000001 /* allocate and init cc_opstate */ >>+ #define CRYPTO_USE_OPSTATE 0x00000002 /* .. start using it as context */ >>+ >> >>The new fields are added to the end of the crypto_ctx_t structure. So, a >>old provider continues to work. Note that a provider should never need to >>allocate this structure since it is allocated by kCF and is passed to >>the provider. >> >>3.3.4. Provider responsibilities >> >>A provider that sets CRYPTO_CAN_SHARE_OPSTATE flag needs to check >>the cc_flags field of crypto_ctx_t argument >> >>a. if routine is init entry point (e.g. encrypt_init()) >> >>check for CRYPTO_INIT_OPSTATE flag. If flag is set and the >>configuration/key material permits sharing >> . allocate the mechanism specific context defined by kCF >> . Initialize the mechanism specific context >> . set CRYPTO_USE_OPSTATE flag in cc_flags field >> . set cc_opstate field to the context >> >>A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE flag. >>For example, a provider needs to do this if the key can not leave the >>hardware keystore. In this case, it should leave cc_opstate field alone. >> >>b. if routine is update entry point (e.g. encrypt_update()) >> >>check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism >>specific context pointed to by cc_opstate >> >>c. A provider frees up cc_opstate at the same time it frees up >>cc_framework_private. So, a provider is in charge of both allocation >>and freeing cc_opstate. >> >> >>3.3.5. Changes to existing providers >> >>KCF providers in ON consolidation are modified to use the >>updated interfaces. These include the software provider, arcfour, >>and the hardware provider, n2cp. >> >> >>4. Bug/RFE Number(s): 6494834 >> >>5. Exported Interfaces: >> >>+--------------------------------+---------------------------+--------------+ >>| Interface | Classification | Comments | >>+--------------------------------+---------------------------+--------------+ >>| crypto_mech_info_t | Consolidation | structure | >>| | Private | | >>| | | | >>| crypto_ctx_t | | structure | >>| | | | >>| arcfour_state_t | | structure | >>| | | | >>| | | | >>| spi.h | | include files | >>| common.h | | | >>| | | | >>+--------------------------------+---------------------------+--------------+ >> >> >>6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >>_______________________________________________ >>crypto-discuss mailing list >>crypto-discuss@opensolaris.org >>http://opensolaris.org/mailman/listinfo/crypto-discuss >> >> >> > > > > --Boundary_(ID_m7cSMnDXXbzPzAgHovZ/0Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi Garrett,

I can only speak for SCA6000 and N2CP, but if the key is not sensitive, the context sharing is possible for AES also.
The context may look something like:
typedef struct {
        uchar_t		keyval[16];
        uchar_t		iv[16];
        uchar_t		unprocessed_data[16];
	uint32_t	unprocessed_data_len;
} aes_state_t;
SW cannot take advantage of the pre-calcurated key shedules, but it may still be faster to process a job in SW in some cases.

-- misaki

Garrett D'Amore wrote:
Hmmm... for most of the hardware crypto engines I've seen, the context
is not necessarily portable.  (I.e. it doesn't conform to any standard
layout, and the details might not be documented.)

RC4 is somewhat unique in this regard, in that the context for RC4 is
fairly trivial.  But RC4 is one of those algorithms where an optimized
CPU version of the algorithm is almost always a better choice.  (I.e.
the cost of DMA setup, etc. usually outweighs any miniscule benefit of
RC4 acceleration.  Additionally, the cost of copying the data is often
close to the cost of doing the algorithm "in place" in the CPU.)

Do we really expect this to have value outside of RC4?  AES would be a
good example, I think.  I've not looked yet at the AES engines that are
commonly available, but I wouldn't be surprised if the "state" for those
engines is really pretty much just a black box.

    -- Garrett

Darren J Moffat wrote:
  
Subject: PSARC FastTrack [02/20/2007]: Crypto Context sharing between providers


Template Version: @(#)sac_nextcase %I% %G% SMI
1. Introduction
    1.1. Project/Component Working Name:
	 Crypto Context sharing between providers
    1.2. Name of Document Author/Supplier:
	 Author:  Krishna Yenduri
    1.3  Date of This Document:
	13 February, 2007
4. Technical Description

Title: Crypto Context sharing between providers

1. Overview

This document describes changes to the Solaris Kernel Cryptographic
SPI to support operation context sharing for improved performance.

The Interface taxonomy is Consolidation Private.
The Release taxonomy is Patch/Micro.

Diff-marked draft manpages, and header files are included
in the case directory.

2. Problem

Many ciphers are faster to do in software for small data sizes. Doing them in
hardware degrades performance instead of helping. Currently, the Solaris
kernel crypto framework (kCF) checks that the input data size for a
crypto operation is above a certain mechanism specific threshold before
it will use a hardware provider. This check is possible only for
atomic kernel API like crypto_encrypt() that do not keep any context across
calls. But, there are many applications which do multi-part requests that
require that context be kept across calls. Also, stream ciphers like RC4
are usable only with multi-part API in SSL.

Currently, these applications that do multi-part API suffer from degraded
performance for smaller data sizes as they will always use the hardware
provider for each part of the multi-part API. So, there is a need
to address this problem. 


3. Solution

The basic idea of the solution is to share the operation context between
a hardware provider and a software provider and use the software provider
for small data sizes and use the hardware provider otherwise. Note that
a hardware provider may not be able share its operation context if the
key object does not allow it. So, the solution is limited to cases where it
is possible to do so.

Initially, we considered using the existing PKCS #11 API
C_GetOperationState/C_SetOperationState for this purpose. But, these API
add overhead for each part of the multi-part API. Also, they are not intended
to be usable across multiple providers. So, we extended the existing service
provider interface (SPI) to enable the sharing of the operation context
with little overhead. We discuss the details below.


3.3 SPI changes

3.3.1. cm_mech_flags field

A provider that can support sharing of context needs to set
CRYPTO_CAN_SHARE_OPSTATE bit flag in the cm_mech_flags field of
crypto_mech_info_t structure.

The existing field, cm_keysize_unit, in the crypto_mech_info_t structure
is an uint32_t and it currently has only two bit flags defined. We rename
this field to cm_mech_flags and maintain cm_keysize_unit as an alias for
cm_mech_flags so that older providers continue to compile.

The advantage with using an existing field rather than adding a new field is that
we avoid having two versions of this structure that will add unnecessary complexity
to kCF to maintain binary compatibility for older providers.


3.3.2. Format of the shared context

The mechanism specific context that is shared between kCF and the provider
is part of the SPI. Initially, we define the context for only the RC4 mechanism.

typedef struct {
        uchar_t arr[256];
        uchar_t i, j;
	uint64_t pad;		/* For 64-bit alignment */
} arcfour_state_t;

We will be adding definitions for other bulk ciphers as needed.


3.3.3. Changes to crypto_ctx_t structure

Two new fields are added to crypto_ctx_t structure
+       uint32_t                cc_flags;               /* flags */
+       void                    *cc_opstate;            /* state */
  } crypto_ctx_t;

+ /* Values for cc_flags field */
+ #define CRYPTO_INIT_OPSTATE     0x00000001 /* allocate and init cc_opstate */
+ #define CRYPTO_USE_OPSTATE      0x00000002 /* .. start using it as context */
+

The new fields are added to the end of the crypto_ctx_t structure. So, a
old provider continues to work. Note that a provider should never need to
allocate this structure since it is allocated by kCF and is passed to
the provider.

3.3.4. Provider responsibilities

A provider that sets CRYPTO_CAN_SHARE_OPSTATE flag needs to check
the cc_flags field of crypto_ctx_t argument

a. if routine is init entry point (e.g. encrypt_init())

check for CRYPTO_INIT_OPSTATE flag. If flag is set and the
configuration/key material permits sharing
 . allocate the mechanism specific context defined by kCF
 . Initialize the mechanism specific context
 . set CRYPTO_USE_OPSTATE flag in cc_flags field
 . set cc_opstate field to the context

A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE flag.
For example, a provider needs to do this if the key can not leave the
hardware keystore. In this case, it should leave cc_opstate field alone.

b. if routine is update entry point (e.g. encrypt_update())

check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism
specific context pointed to by cc_opstate

c. A provider frees up cc_opstate at the same time it frees up
cc_framework_private. So, a provider is in charge of both allocation
and freeing cc_opstate.


3.3.5. Changes to existing providers

KCF providers in ON consolidation are modified to use the
updated interfaces. These include the software provider, arcfour,
and the hardware provider, n2cp.


4. Bug/RFE Number(s): 6494834

5. Exported Interfaces:

+--------------------------------+---------------------------+--------------+
|   Interface                    |  Classification           | Comments     |
+--------------------------------+---------------------------+--------------+
| crypto_mech_info_t		 | Consolidation             | structure    |
|                                | Private                   |              |
|                                |                           |              |
| crypto_ctx_t			 |                           | structure    |
|                                |                           |              |
| arcfour_state_t                |                           | structure    |
|                                |                           |              |
|                                |                           |              |
|   spi.h                        |                           | include files |
|   common.h		         |                           |              |
|                                |                           |              |
+--------------------------------+---------------------------+--------------+


6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
_______________________________________________
crypto-discuss mailing list
crypto-discuss@opensolaris.org
http://opensolaris.org/mailman/listinfo/crypto-discuss
--Boundary_(ID_m7cSMnDXXbzPzAgHovZ/0Q)-- From sacadmin Tue Feb 13 15:46:36 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DNkaBJ012976 for ; Tue, 13 Feb 2007 15:46:36 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l1DNkZlt018222 for ; Tue, 13 Feb 2007 15:46:35 -0800 (PST) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1DNkZew028554 for ; Tue, 13 Feb 2007 16:46:35 -0700 (MST) Received: from mms27es.sun.com ([150.143.232.134] [150.143.232.134]) by relay24.sun.com with ESMTP; Tue, 13 Feb 2007 23:46:34 Z Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms27es.sun.com with ESMTP; Tue, 13 Feb 2007 23:46:34 Z Received: from mail.tadpolecomputer.co.uk ([82.111.17.14] [82.111.17.14]) by relay22.sun.com with ESMTP; Tue, 13 Feb 2007 23:46:33 Z Received: from zippy.garrett ([192.168.251.21]) by mail.tadpolecomputer.co.uk with esmtp (Exim 4.66) (envelope-from ) id 1HH7M0-0005A6-Md; Tue, 13 Feb 2007 23:46:33 +0000 Message-Id: <45D24DD6.10802@tadpole.com> Date: Tue, 13 Feb 2007 15:46:30 -0800 From: "Garrett D'Amore" User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Misaki Kataoka CC: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> <45D23E30.70807@tadpole.com> <45D24993.5020005@sun.com> In-Reply-To: <45D24993.5020005@sun.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 9589 Good point, Misaki -- I wasn't thinking properly about block ciphers, and had my brain stuck on the key schedule. But you're precisely right, all you need is the IV and the original data to keep processing. :-) -- Garrett Misaki Kataoka wrote: > Hi Garrett, > > I can only speak for SCA6000 and N2CP, but if the key is not > sensitive, the context sharing is possible for AES also. > The context may look something like: > typedef struct { > uchar_t keyval[16]; > uchar_t iv[16]; > uchar_t unprocessed_data[16]; > uint32_t unprocessed_data_len; > } aes_state_t; > SW cannot take advantage of the pre-calcurated key shedules, but it > may still be faster to process a job in SW in some cases. > > -- misaki > > Garrett D'Amore wrote: >> Hmmm... for most of the hardware crypto engines I've seen, the context >> is not necessarily portable. (I.e. it doesn't conform to any standard >> layout, and the details might not be documented.) >> >> RC4 is somewhat unique in this regard, in that the context for RC4 is >> fairly trivial. But RC4 is one of those algorithms where an optimized >> CPU version of the algorithm is almost always a better choice. (I.e. >> the cost of DMA setup, etc. usually outweighs any miniscule benefit of >> RC4 acceleration. Additionally, the cost of copying the data is often >> close to the cost of doing the algorithm "in place" in the CPU.) >> >> Do we really expect this to have value outside of RC4? AES would be a >> good example, I think. I've not looked yet at the AES engines that are >> commonly available, but I wouldn't be surprised if the "state" for those >> engines is really pretty much just a black box. >> >> -- Garrett >> >> Darren J Moffat wrote: >> >>> Subject: PSARC FastTrack [02/20/2007]: Crypto Context sharing between providers >>> >>> >>> Template Version: @(#)sac_nextcase %I% %G% SMI >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Crypto Context sharing between providers >>> 1.2. Name of Document Author/Supplier: >>> Author: Krishna Yenduri >>> 1.3 Date of This Document: >>> 13 February, 2007 >>> 4. Technical Description >>> >>> Title: Crypto Context sharing between providers >>> >>> 1. Overview >>> >>> This document describes changes to the Solaris Kernel Cryptographic >>> SPI to support operation context sharing for improved performance. >>> >>> The Interface taxonomy is Consolidation Private. >>> The Release taxonomy is Patch/Micro. >>> >>> Diff-marked draft manpages, and header files are included >>> in the case directory. >>> >>> 2. Problem >>> >>> Many ciphers are faster to do in software for small data sizes. Doing them in >>> hardware degrades performance instead of helping. Currently, the Solaris >>> kernel crypto framework (kCF) checks that the input data size for a >>> crypto operation is above a certain mechanism specific threshold before >>> it will use a hardware provider. This check is possible only for >>> atomic kernel API like crypto_encrypt() that do not keep any context across >>> calls. But, there are many applications which do multi-part requests that >>> require that context be kept across calls. Also, stream ciphers like RC4 >>> are usable only with multi-part API in SSL. >>> >>> Currently, these applications that do multi-part API suffer from degraded >>> performance for smaller data sizes as they will always use the hardware >>> provider for each part of the multi-part API. So, there is a need >>> to address this problem. >>> >>> >>> 3. Solution >>> >>> The basic idea of the solution is to share the operation context between >>> a hardware provider and a software provider and use the software provider >>> for small data sizes and use the hardware provider otherwise. Note that >>> a hardware provider may not be able share its operation context if the >>> key object does not allow it. So, the solution is limited to cases where it >>> is possible to do so. >>> >>> Initially, we considered using the existing PKCS #11 API >>> C_GetOperationState/C_SetOperationState for this purpose. But, these API >>> add overhead for each part of the multi-part API. Also, they are not intended >>> to be usable across multiple providers. So, we extended the existing service >>> provider interface (SPI) to enable the sharing of the operation context >>> with little overhead. We discuss the details below. >>> >>> >>> 3.3 SPI changes >>> >>> 3.3.1. cm_mech_flags field >>> >>> A provider that can support sharing of context needs to set >>> CRYPTO_CAN_SHARE_OPSTATE bit flag in the cm_mech_flags field of >>> crypto_mech_info_t structure. >>> >>> The existing field, cm_keysize_unit, in the crypto_mech_info_t structure >>> is an uint32_t and it currently has only two bit flags defined. We rename >>> this field to cm_mech_flags and maintain cm_keysize_unit as an alias for >>> cm_mech_flags so that older providers continue to compile. >>> >>> The advantage with using an existing field rather than adding a new field is that >>> we avoid having two versions of this structure that will add unnecessary complexity >>> to kCF to maintain binary compatibility for older providers. >>> >>> >>> 3.3.2. Format of the shared context >>> >>> The mechanism specific context that is shared between kCF and the provider >>> is part of the SPI. Initially, we define the context for only the RC4 mechanism. >>> >>> typedef struct { >>> uchar_t arr[256]; >>> uchar_t i, j; >>> uint64_t pad; /* For 64-bit alignment */ >>> } arcfour_state_t; >>> >>> We will be adding definitions for other bulk ciphers as needed. >>> >>> >>> 3.3.3. Changes to crypto_ctx_t structure >>> >>> Two new fields are added to crypto_ctx_t structure >>> + uint32_t cc_flags; /* flags */ >>> + void *cc_opstate; /* state */ >>> } crypto_ctx_t; >>> >>> + /* Values for cc_flags field */ >>> + #define CRYPTO_INIT_OPSTATE 0x00000001 /* allocate and init cc_opstate */ >>> + #define CRYPTO_USE_OPSTATE 0x00000002 /* .. start using it as context */ >>> + >>> >>> The new fields are added to the end of the crypto_ctx_t structure. So, a >>> old provider continues to work. Note that a provider should never need to >>> allocate this structure since it is allocated by kCF and is passed to >>> the provider. >>> >>> 3.3.4. Provider responsibilities >>> >>> A provider that sets CRYPTO_CAN_SHARE_OPSTATE flag needs to check >>> the cc_flags field of crypto_ctx_t argument >>> >>> a. if routine is init entry point (e.g. encrypt_init()) >>> >>> check for CRYPTO_INIT_OPSTATE flag. If flag is set and the >>> configuration/key material permits sharing >>> . allocate the mechanism specific context defined by kCF >>> . Initialize the mechanism specific context >>> . set CRYPTO_USE_OPSTATE flag in cc_flags field >>> . set cc_opstate field to the context >>> >>> A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE flag. >>> For example, a provider needs to do this if the key can not leave the >>> hardware keystore. In this case, it should leave cc_opstate field alone. >>> >>> b. if routine is update entry point (e.g. encrypt_update()) >>> >>> check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism >>> specific context pointed to by cc_opstate >>> >>> c. A provider frees up cc_opstate at the same time it frees up >>> cc_framework_private. So, a provider is in charge of both allocation >>> and freeing cc_opstate. >>> >>> >>> 3.3.5. Changes to existing providers >>> >>> KCF providers in ON consolidation are modified to use the >>> updated interfaces. These include the software provider, arcfour, >>> and the hardware provider, n2cp. >>> >>> >>> 4. Bug/RFE Number(s): 6494834 >>> >>> 5. Exported Interfaces: >>> >>> +--------------------------------+---------------------------+--------------+ >>> | Interface | Classification | Comments | >>> +--------------------------------+---------------------------+--------------+ >>> | crypto_mech_info_t | Consolidation | structure | >>> | | Private | | >>> | | | | >>> | crypto_ctx_t | | structure | >>> | | | | >>> | arcfour_state_t | | structure | >>> | | | | >>> | | | | >>> | spi.h | | include files | >>> | common.h | | | >>> | | | | >>> +--------------------------------+---------------------------+--------------+ >>> >>> >>> 6. Resources and Schedule >>> 6.4. Steering Committee requested information >>> 6.4.1. Consolidation C-team Name: >>> ON >>> 6.5. ARC review type: FastTrack >>> _______________________________________________ >>> crypto-discuss mailing list >>> crypto-discuss@opensolaris.org >>> http://opensolaris.org/mailman/listinfo/crypto-discuss >>> >>> >> >> >> -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 From sacadmin Tue Feb 13 15:53:39 2007 Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DNrcX0013110 for ; Tue, 13 Feb 2007 15:53:39 -0800 (PST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1DNr1OL009943; Tue, 13 Feb 2007 17:53:01 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.6+Sun/8.13.6/Submit) id l1DNr08R009942; Tue, 13 Feb 2007 17:53:00 -0600 (CST) Date: Tue, 13 Feb 2007 17:53:00 -0600 From: Nicolas Williams To: "Garrett D'Amore" Cc: Misaki Kataoka , Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] Message-ID: <20070213235300.GQ9435@binky.central.sun.com> References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> <45D23E30.70807@tadpole.com> <45D24993.5020005@sun.com> <45D24DD6.10802@tadpole.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D24DD6.10802@tadpole.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 673 On Tue, Feb 13, 2007 at 03:46:30PM -0800, Garrett D'Amore wrote: > Good point, Misaki -- I wasn't thinking properly about block ciphers, > and had my brain stuck on the key schedule. But you're precisely right, > all you need is the IV and the original data to keep processing. :-) The exact abstract form of the cipher state will depend on the cipher mode too. E.g., think about AD/AEAD modes vs., say, CBC. For something like ECB (e.g., for computing a counter mode pad) the cipher state will be trivial :), for CBC the cipher state is also trivial (the last output ciphertext block being the next IV), for GCM, CCM, LRW and others it will be more complex. Nico -- From sacadmin Tue Feb 13 18:35:03 2007 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1E2Z2fk015576 for ; Tue, 13 Feb 2007 18:35:02 -0800 (PST) Received: from [129.146.108.66] (bluesky.SFBay.Sun.COM [129.146.108.66]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l1E2Z1P27625; Tue, 13 Feb 2007 18:35:02 -0800 (PST) Message-ID: <45D27543.6010809@Sun.COM> Date: Tue, 13 Feb 2007 18:34:43 -0800 From: Krishna Yenduri User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: "Garrett D'Amore" CC: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: [crypto-discuss] Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> <45D23E30.70807@tadpole.com> In-Reply-To: <45D23E30.70807@tadpole.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1482 Garrett D'Amore wrote: > Hmmm... for most of the hardware crypto engines I've seen, the context > is not necessarily portable. (I.e. it doesn't conform to any standard > layout, and the details might not be documented.) A driver that uses a different mechanism context structure can still support the new feature if it can translate its structure to the one defined by KCF. > RC4 is somewhat unique in this regard, in that the context for RC4 is > fairly trivial. But RC4 is one of those algorithms where an optimized > CPU version of the algorithm is almost always a better choice. (I.e. > the cost of DMA setup, etc. usually outweighs any miniscule benefit of > RC4 acceleration. Additionally, the cost of copying the data is often > close to the cost of doing the algorithm "in place" in the CPU.) There is no copying of data by KCF. Even for RC4, as the input buffer size increases (think 16K for an SSL record) the hardware acceleration helps. > Do we really expect this to have value outside of RC4? AES would be a > good example, I think. Yes. AES case will be even more useful. And the AES context, as Misaki pointed out, is not complex. A follow up case will define block cipher context formats in KCF. That will likely include AES, and 3DES. Thanks, -Krishna I've not looked yet at the AES engines that are > commonly available, but I wouldn't be surprised if the "state" for those > engines is really pretty much just a black box. From sacadmin Wed Feb 14 12:52:10 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EKqAsW008572 for ; Wed, 14 Feb 2007 12:52:10 -0800 (PST) Received: from [129.145.154.105] (sr1-umpk-55.SFBay.Sun.COM [129.145.154.105]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1EKq92u171917; Wed, 14 Feb 2007 12:52:09 -0800 (PST) Message-ID: <45D37679.7090807@Sun.COM> Date: Wed, 14 Feb 2007 12:52:09 -0800 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060120 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Darren J Moffat CC: PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> In-Reply-To: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2041 >a. if routine is init entry point (e.g. encrypt_init()) > >check for CRYPTO_INIT_OPSTATE flag. If flag is set and the >configuration/key material permits sharing > . allocate the mechanism specific context defined by kCF > . Initialize the mechanism specific context > . set CRYPTO_USE_OPSTATE flag in cc_flags field > . set cc_opstate field to the context > >A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE flag. >For example, a provider needs to do this if the key can not leave the >hardware keystore. In this case, it should leave cc_opstate field alone. > > any impact on the load balancing between multiple h/w providers of the same algorithm when some can do CRYPTO_INIT_OPSTATE and some cannot? (thinking about the case where those that cannot happen to get registered first, and get selected systematically first, causing sub-optimal overall performance with smaller packets). >b. if routine is update entry point (e.g. encrypt_update()) > >check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism >specific context pointed to by cc_opstate > > let's see: int (*encrypt_update)(crypto_ctx_t *, crypto_data_t *, crypto_data_t *, crypto_req_handle_t); the crypto_ctx_t carries a provider specific handle. So, do you ask providers that take over where another one had started the op to ignore the crypto_ctx->cc_provider_private ? or does the framework internally call their (*encrypt_init)(crypto_ctx_t *, ... crypto_mechanism_t *, crypto_key_t *, crypto_spi_ctx_template_t, crypto_req_handle_t)); so that they get to initialize it properly, in case they need to keep information about the call itself (e.g. some sort of validation, access control, stats ...) not related to the cryptographic context of the multipart op? >c. A provider frees up cc_opstate at the same time it frees up >cc_framework_private. So, a provider is in charge of both allocation > > you mean cc_provider_private ? Kais >and freeing cc_opstate. > > > > From sacadmin Wed Feb 14 15:26:28 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1ENQSQb001744 for ; Wed, 14 Feb 2007 15:26:28 -0800 (PST) Received: from [129.146.108.66] (bluesky.SFBay.Sun.COM [129.146.108.66]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1EN3rmx228719; Wed, 14 Feb 2007 15:03:53 -0800 (PST) Message-ID: <45D39546.7040909@sun.com> Date: Wed, 14 Feb 2007 15:03:34 -0800 From: Krishna Yenduri User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060731 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kais Belgaied CC: Darren J Moffat , PSARC@sac.sfbay.sun.com, crypto-discuss@opensolaris.org Subject: Re: Crypto Context sharing between providers [PSARC/2007/093 Timeout: 02/20/2007] References: <200702132225.l1DMP57q349271@jurassic.eng.sun.com> <45D37679.7090807@Sun.COM> In-Reply-To: <45D37679.7090807@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2554 Kais Belgaied wrote: >> a. if routine is init entry point (e.g. encrypt_init()) >> >> check for CRYPTO_INIT_OPSTATE flag. If flag is set and the >> configuration/key material permits sharing >> . allocate the mechanism specific context defined by kCF >> . Initialize the mechanism specific context >> . set CRYPTO_USE_OPSTATE flag in cc_flags field >> . set cc_opstate field to the context >> >> A provider can refuse sharing by NOT setting the CRYPTO_USE_OPSTATE >> flag. >> For example, a provider needs to do this if the key can not leave the >> hardware keystore. In this case, it should leave cc_opstate field alone. >> >> > > any impact on the load balancing between multiple h/w providers of the > same > algorithm when some can do CRYPTO_INIT_OPSTATE and some cannot? > (thinking about the case where those that cannot happen to get registered > first, and get selected systematically first, causing sub-optimal overall > performance with smaller packets). The decision on which h/w provider to use is made at the time of crypto_encrypt_init(). So, this feature does not change the current situation as far as load balancing is concerned. Regarding your observation about the first provider, we have 6416204 kCF could use a different metric than tq_nalloc to get the load on a provider to address that. >> b. if routine is update entry point (e.g. encrypt_update()) >> >> check for CRYPTO_USE_OPSTATE flag. If flag is set, use/update mechanism >> specific context pointed to by cc_opstate >> >> > let's see: > > int (*encrypt_update)(crypto_ctx_t *, > crypto_data_t *, crypto_data_t *, crypto_req_handle_t); > > the crypto_ctx_t carries a provider specific handle. > So, do you ask providers that take over where another one had started > the op > to ignore the crypto_ctx->cc_provider_private ? Yes. I will make that explicit. > or does the framework internally call their > (*encrypt_init)(crypto_ctx_t *, ... > crypto_mechanism_t *, crypto_key_t *, > crypto_spi_ctx_template_t, crypto_req_handle_t)); > > so that they get to initialize it properly, in case they need to keep > information about > the call itself (e.g. some sort of validation, access control, stats > ...) not related to the > cryptographic context of the multipart op? > >> c. A provider frees up cc_opstate at the same time it frees up >> cc_framework_private. So, a provider is in charge of both allocation >> >> > you mean cc_provider_private ? Yes. I meant cc_provider_private. Thanks, -Krishna From sacadmin Fri Feb 23 04:07:11 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1NC7ABJ013325 for ; Fri, 23 Feb 2007 04:07:11 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l1NC705S004891 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 23 Feb 2007 12:07:09 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JDX004030BV6800@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Feb 2007 04:07:07 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JDX000IH0BTQR90@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Feb 2007 04:07:05 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1NC74ri009437 for ; Fri, 23 Feb 2007 12:07:04 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDX00C010B6NQ00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Feb 2007 12:07:04 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDX00FII0BNNZ00@d1-emea-09.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Feb 2007 12:07:01 +0000 (GMT) Date: Fri, 23 Feb 2007 12:06:59 +0000 From: Darren J Moffat Subject: Crypto Context sharing between providers [PSARC/2007/093 closed-approved] Sender: Darren.Moffat@sun.com To: psarc@sun.com, crypto-discuss@opensolaris.org Message-id: <45DED8E3.2060700@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 153 There are no unresolved issues and the timer has expired. The final spec, with the one correction, is in the case dir as spec.txt. -- Darren J Moffat