From sacadmin Wed Apr 11 18:49:52 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3C1nqXH013868; Wed, 11 Apr 2007 18:49:52 -0700 (PDT) Received: (from krishna@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l3C1nqw0013864; Wed, 11 Apr 2007 18:49:52 -0700 (PDT) Date: Wed, 11 Apr 2007 18:49:52 -0700 (PDT) From: Krishna Yenduri Message-Id: <200704120149.l3C1nqw0013864@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: crypto-discuss@opensolaris.org Subject: Support KCF Providers with Limited Digest Capability [PSARC/2007/213 Timeout: 04/11/2007] Status: RO Content-Length: 3798 Subject: PSARC FastTrack [04/11/2007]: Support KCF Providers with Limited Digest Capability I am self-sponsoring the following case and marking it as "closed approved automatic". It only modifies consolidation private interfaces and does so in a compatible way. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2007 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Support KCF Providers with Limited Digest Capability 1.2. Name of Document Author/Supplier: Author: Krishna Yenduri 1.3 Date of This Document: 11 April, 2007 4. Technical Description 1. Overview This document describes changes to the Solaris Kernel Cryptographic SPI to support hardware providers with limitation. The Interface taxonomy is Consolidation Private. The Release taxonomy is Patch/Micro. 2. Problem Some crypto accelerator products like Sun Crypto Accelerator 6000 have a limit on the maximum input data that they can digest and hence can not do multi-part digest (and HMAC which uses a digest) operations. They can do single-part digest operation provided the input data size is below the maximum supported value. Currently, these providers when registered with Solaris Crypto Framework can not export the digest mechanisms at all. This limitation prevents PKCS #11 applications and some kernel clients from accelerating the digest operations using the hardware. So, there is a need to solve this limitation and enable consumers to use the hardware as much as possible. 3. Solution We relax the existing constraint that a provider must support multi-part digest routines to be able to set CRYPTO_FG_DIGEST flag for a digest mechanism. A provider is now allowed to export only a single-part digest routine and still set the CRYPTO_FG_DIGEST flag. A provider with the limitation needs to do the following: 1. Set the CRYPTO_LIMITED_HASH_SUPPORT flag, in pi_flags field of the crypto_provider_info_t structure, to indicate this limitation. 2. For each digest mechanism, specify the maximum buffer length it can digest in the cm_max_input_length field in crypto_mech_info_t structure and set the CRYPTO_FG_DIGEST flag in cm_func_group_mask field. 3. Return the error code, CRYPTO_BUFFER_TOO_BIG, if it gets an input buffer greater than the maximum supported length. The framework will use only the digest_init and digest SPI routines from such a provider. It will not use the routines - digest_update, digest_key, and digest_final from the provider. 3.1. Compatibility issues The size of crypto_mech_info_t structure remains unchanged as the field cm_max_input_length is an alias for the existing field, cm_max_key_length. We can safely do this because cm_max_key_length field is unused for a digest mechanism. There is no change in use of cm_max_key_length field for a HMAC mechanism. The framework will get the limit on maximum input data from the underlying digest used by the HMAC mechanism. 4. Bug/RFE Number(s): 6473274 5. Exported Interfaces: +--------------------------------+---------------------------+--------------+ | Interface | Classification | Comments | +--------------------------------+---------------------------+--------------+ | | | | | spi.h | Consolidation | include file | | | Private | | | | | | +--------------------------------+---------------------------+--------------+ 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 Bhargava.Yenduri@sun.com Thu Apr 12 13:54:36 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3CKsZJr022427 for ; Thu, 12 Apr 2007 13:54:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3CKrp8G015333 for <@newsunmail1brm.central.sun.com:psarc-ext@Sun.COM>; Fri, 13 Apr 2007 04:53:55 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGE00801KPSLD00@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 12 Apr 2007 14:53:52 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGE00CG4KPR1PD0@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 12 Apr 2007 14:53:51 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3CKrpWe005282; Thu, 12 Apr 2007 13:53:51 -0700 (PDT) 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 l3CKroT22843; Thu, 12 Apr 2007 13:53:50 -0700 (PDT) Date: Thu, 12 Apr 2007 13:52:56 -0700 From: Krishna Yenduri Subject: PSARC/2007/213 Support KCF Providers with Limited Digest Capability To: psarc-ext@sun.com Cc: crypto-discuss@opensolaris.org Message-id: <461E9C28.1010100@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QKa2O1MoQ49gqK8ckqcEXA)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060731 Status: RO Content-Length: 4156 This is a multi-part message in MIME format. --Boundary_(ID_QKa2O1MoQ49gqK8ckqcEXA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I am self-sponsoring the following case and marking it as "closed approved automatic". It only modifies consolidation private interfaces and does so in a compatible way. Regards, -Krishna --Boundary_(ID_QKa2O1MoQ49gqK8ckqcEXA) Content-type: text/plain; name=spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.txt 1. Introduction 1.1. Project/Component Working Name: Support KCF Providers with Limited Digest Capability 1.2. Name of Document Author/Supplier: Author: Krishna Yenduri 1.3 Date of This Document: 11 April, 2007 4. Technical Description 1. Overview This document describes changes to the Solaris Kernel Cryptographic SPI to support hardware providers with limitation. The Interface taxonomy is Consolidation Private. The Release taxonomy is Patch/Micro. 2. Problem Some crypto accelerator products like Sun Crypto Accelerator 6000 have a limit on the maximum input data that they can digest and hence can not do multi-part digest (and HMAC which uses a digest) operations. They can do single-part digest operation provided the input data size is below the maximum supported value. Currently, these providers when registered with Solaris Crypto Framework can not export the digest mechanisms at all. This limitation prevents PKCS #11 applications and some kernel clients from accelerating the digest operations using the hardware. So, there is a need to solve this limitation and enable consumers to use the hardware as much as possible. 3. Solution We relax the existing constraint that a provider must support multi-part digest routines to be able to set CRYPTO_FG_DIGEST flag for a digest mechanism. A provider is now allowed to export only a single-part digest routine and still set the CRYPTO_FG_DIGEST flag. A provider with the limitation needs to do the following: 1. Set the CRYPTO_LIMITED_HASH_SUPPORT flag, in pi_flags field of the crypto_provider_info_t structure, to indicate this limitation. This is a new flag added to spi.h. 2. For each digest mechanism, specify the maximum buffer length it can digest in the cm_max_input_length field in crypto_mech_info_t structure and set the CRYPTO_FG_DIGEST flag in cm_func_group_mask field. 3. Return the error code, CRYPTO_BUFFER_TOO_BIG, if it gets an input buffer greater than the maximum supported length. The framework will use only the digest_init and digest SPI routines from such a provider. It will not use the routines - digest_update, digest_key, and digest_final from the provider. 3.1. Compatibility issues The size of crypto_mech_info_t structure remains unchanged as the field cm_max_input_length is an alias for the existing field, cm_max_key_length. We can safely do this because cm_max_key_length field is unused for a digest mechanism. There is no change in use of cm_max_key_length field for a HMAC mechanism. The framework will get the limit on maximum input data from the underlying digest used by the HMAC mechanism. 4. Bug/RFE Number(s): 6473274 5. Exported Interfaces: +--------------------------------+---------------------------+--------------+ | Interface | Classification | Comments | +--------------------------------+---------------------------+--------------+ | | | | | spi.h | Consolidation | include file | | | Private | | | | | | +--------------------------------+---------------------------+--------------+ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack --Boundary_(ID_QKa2O1MoQ49gqK8ckqcEXA)-- From Bhargava.Yenduri@Sun.COM Thu Apr 12 17:17:31 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3D0HVFL000050 for ; Thu, 12 Apr 2007 17:17:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3D0GiJZ019502 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@Sun.COM>; Fri, 13 Apr 2007 01:16:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGE00101U41J700@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 12 Apr 2007 17:16:49 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGE00C04U40I9B0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 12 Apr 2007 17:16:48 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3D0GmNK012453; Thu, 12 Apr 2007 17:16:48 -0700 (PDT) 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 l3D0GlT25831; Thu, 12 Apr 2007 17:16:47 -0700 (PDT) Date: Thu, 12 Apr 2007 17:15:54 -0700 From: Krishna Yenduri Subject: Re: [crypto-discuss] PSARC/2007/213 Support KCF Providers with Limited Digest Capability In-reply-to: <461EBF17.5070001@damore.org> To: "Garrett D'Amore" Cc: crypto-discuss@opensolaris.org, psarc-ext@Sun.COM Message-id: <461ECBBA.4010706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <461E99F2.6010304@Sun.COM> <461EBF17.5070001@damore.org> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060731 Status: RO Content-Length: 718 Garrett D'Amore wrote: > Krishna Yenduri wrote: > >> ... >> >> I am self-sponsoring the following case and marking it as >> "closed approved automatic". It only modifies consolidation private >> interfaces and does so in a compatible way. >> ... > > > I would rather not use CRYPTO_LIMITED_HASH_SUPPORT as a flag... that's > a bit unclear... i.e. how is it limited. How about, instead, > CRYPTO_HASH_NO_UPDATE ... which I think is better at conveying what > you really want to express. The provider has a limit on the size of the input data that it can digest. Hence it can not do update (mulit-part) operations. They are cause and effect :-). So, I would like to keep the existing name. Thanks, -Krishna From garrett@damore.org Thu Apr 12 17:24:49 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3D0OmvN000243 for ; Thu, 12 Apr 2007 17:24:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3D0O6Vr021034; Fri, 13 Apr 2007 01:24:07 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGE00601UG65600@brm-avmta-1.central.sun.com>; Thu, 12 Apr 2007 18:24:06 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGE009WNUG5KP80@brm-avmta-1.central.sun.com>; Thu, 12 Apr 2007 18:24:05 -0600 (MDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3CNiVe0004821; Fri, 13 Apr 2007 00:24:05 +0000 (GMT) Received: from mms03es.sun.com ([150.143.104.54] [150.143.104.54]) by relay1.sun.com with ESMTP id BT-MMP-358685; Fri, 13 Apr 2007 00:24:05 +0000 (Z) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54]) by mms03es.sun.com with ESMTP id BT-MMP-678843; Fri, 13 Apr 2007 00:24:04 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay3.sun.com with ESMTP id BT-MMP-2452203; Fri, 13 Apr 2007 00:24:04 +0000 (Z) Received: from cpe-76-174-83-55.socal.res.rr.com ([76.174.83.55] helo=[192.168.251.21]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Hc9aB-0001f2-Op; Thu, 12 Apr 2007 17:24:07 -0700 Date: Thu, 12 Apr 2007 17:23:42 -0700 From: "Garrett D'Amore" Subject: Re: [crypto-discuss] PSARC/2007/213 Support KCF Providers with Limited Digest Capability In-reply-to: <461ECBBA.4010706@Sun.COM> To: Krishna Yenduri Cc: crypto-discuss@opensolaris.org, psarc-ext@sun.com Message-id: <461ECD8E.7090504@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org X-Source: X-Source-Args: X-Source-Dir: References: <461E99F2.6010304@Sun.COM> <461EBF17.5070001@damore.org> <461ECBBA.4010706@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1725 Krishna Yenduri wrote: > Garrett D'Amore wrote: > >> Krishna Yenduri wrote: >> >>> ... >>> >>> I am self-sponsoring the following case and marking it as >>> "closed approved automatic". It only modifies consolidation private >>> interfaces and does so in a compatible way. >>> ... >> >> >> I would rather not use CRYPTO_LIMITED_HASH_SUPPORT as a flag... >> that's a bit unclear... i.e. how is it limited. How about, instead, >> CRYPTO_HASH_NO_UPDATE ... which I think is better at conveying what >> you really want to express. > > > The provider has a limit on the size of the input data that it can > digest. > Hence it can not do update (mulit-part) operations. They are cause and > effect :-). > So, I would like to keep the existing name. The cause and effect relationship don't matter. What you want to do is understand what the API means. Just saying its "limited" without some explanation, isn't helpful. The implications for a consumer application, is that UPDATE doesn't work. Then that is what the API should express. And, indeed, that is what the API actually does. The underlying cause of _why_ UPDATE isn't supported isn't interesting... FWIW, if this is a Broadcom 582x based device as well, then I _suspect_ that the problem is really that the chip in fact does not support UPDATE. The size limitation is just a side effect of that. (Most likely the MARS firmware is just copying all data up into the host, so it can submit it as a single job.) Indeed, if a device really did support UPDATE, then you could easily provide support for large jobs just by doing multiple UPDATEs. In other words, I think your cause and effect are _also_ wrong. -- Garrett > > Thanks, > -Krishna From Bhargava.Yenduri@Sun.COM Thu Apr 12 18:54:03 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3D1s2YL004619 for ; Thu, 12 Apr 2007 18:54:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3D1r68M010389 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@Sun.COM>; Fri, 13 Apr 2007 09:53:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGE00603YKVGK00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 12 Apr 2007 18:53:19 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGE00CQIYKVI2C0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 12 Apr 2007 18:53:19 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3D1rJFR015221; Thu, 12 Apr 2007 18:53:19 -0700 (PDT) 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 l3D1rIT26583; Thu, 12 Apr 2007 18:53:18 -0700 (PDT) Date: Thu, 12 Apr 2007 18:52:25 -0700 From: Krishna Yenduri Subject: Re: [crypto-discuss] PSARC/2007/213 Support KCF Providers with Limited Digest Capability In-reply-to: <461ECD8E.7090504@damore.org> To: "Garrett D'Amore" Cc: psarc-ext@Sun.COM, crypto-discuss@opensolaris.org Message-id: <461EE259.7070309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <461E99F2.6010304@Sun.COM> <461EBF17.5070001@damore.org> <461ECBBA.4010706@Sun.COM> <461ECD8E.7090504@damore.org> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060731 Status: RO Content-Length: 2199 Garrett D'Amore wrote: >>> ... >>> >>> I would rather not use CRYPTO_LIMITED_HASH_SUPPORT as a flag... >>> that's a bit unclear... i.e. how is it limited. How about, instead, >>> CRYPTO_HASH_NO_UPDATE ... which I think is better at conveying what >>> you really want to express. >> >> >> >> The provider has a limit on the size of the input data that it can >> digest. >> Hence it can not do update (mulit-part) operations. They are cause >> and effect :-). >> So, I would like to keep the existing name. > > > The cause and effect relationship don't matter. What you want to do > is understand what the API means. Just saying its "limited" without > some explanation, isn't helpful. > > The implications for a consumer application, is that UPDATE doesn't > work. Then that is what the API should express. And, indeed, that is > what the API actually does. This is one part. The other part is that for the consumer application (which is KCF here) a single call does not work if it is above certain size. > The underlying cause of _why_ UPDATE isn't supported isn't interesting... > FWIW, if this is a Broadcom 582x based device as well, then I > _suspect_ that the problem is really that the chip in fact does not > support UPDATE. I believe this is true. The digest implementation logic in this hardware finalizes the hash for each digest request from the driver. The finalizing step for MD5 and SHA1 does some padding and so there is no way to build a hash of a larger message from its parts. > The size limitation is just a side effect of that. (Most likely the > MARS firmware is just copying all data up into the host, so it can > submit it as a single job.) If there were no size limit, then the driver can batch up multiple UPDATEs in to single call and so can still claim to support UPDATEs. Of course, in practice, there will be a limit on kernel memory consumed by the driver. > Indeed, if a device really did support UPDATE, then you could easily > provide support for large jobs just by doing multiple UPDATEs. Agreed. You have convinced me that CRYPTO_HASH_NO_UPDATE is a better name. I will update the proposal. Thanks, -Krishna From Bhargava.Yenduri@sun.com Fri Apr 13 10:49:51 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3DHnoHm002243 for ; Fri, 13 Apr 2007 10:49:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3DHn86x013262 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Fri, 13 Apr 2007 10:49:12 -0700 (PDT) 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 <0JGG0062L6TZQS00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 13 Apr 2007 10:49:11 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGG0010Y6TZ1380@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 13 Apr 2007 10:49:11 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l3DHnA9i025692; Fri, 13 Apr 2007 10:49:10 -0700 (PDT) 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 l3DHnAT02404; Fri, 13 Apr 2007 10:49:10 -0700 (PDT) Date: Fri, 13 Apr 2007 10:48:15 -0700 From: Krishna Yenduri Subject: Re: [crypto-discuss] PSARC/2007/213 Support KCF Providers with Limited Digest Capability In-reply-to: <461EE259.7070309@Sun.COM> To: psarc-ext@sun.com Cc: crypto-discuss@opensolaris.org Message-id: <461FC25F.4070001@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GsDrdg4YMF5akZ7982NrMQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <461E99F2.6010304@Sun.COM> <461EBF17.5070001@damore.org> <461ECBBA.4010706@Sun.COM> <461ECD8E.7090504@damore.org> <461EE259.7070309@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060731 Status: RO Content-Length: 3973 This is a multi-part message in MIME format. --Boundary_(ID_GsDrdg4YMF5akZ7982NrMQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I have updated the spec to rename the flag and clarify the text in the problem section. It is attached. -Krishna --Boundary_(ID_GsDrdg4YMF5akZ7982NrMQ) Content-type: text/plain; name=updated_spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=updated_spec.txt 1. Introduction 1.1. Project/Component Working Name: Support KCF Providers with Limited Digest Capability 1.2. Name of Document Author/Supplier: Author: Krishna Yenduri 1.3 Date of This Document: 13 April, 2007 4. Technical Description 1. Overview This document describes changes to the Solaris Kernel Cryptographic SPI to support hardware providers with limitation. The Interface taxonomy is Consolidation Private. The Release taxonomy is Patch/Micro. 2. Problem Some crypto accelerator products like Sun Crypto Accelerator 6000 can not do multi-part digest (and HMAC which uses a digest) operations and have a limit on the maximum input data that they can digest. They can do single-part digest operation provided the input data size is below the maximum supported value. Currently, these providers when registered with Solaris Crypto Framework can not export the digest mechanisms at all. This limitation prevents PKCS #11 applications and some kernel clients from accelerating the digest operations using the hardware. So, there is a need to solve this limitation and enable consumers to use the hardware as much as possible. 3. Solution We relax the existing constraint that a provider must support multi-part digest routines to be able to set CRYPTO_FG_DIGEST flag for a digest mechanism. A provider is now allowed to export only a single-part digest routine and still set the CRYPTO_FG_DIGEST flag. A provider with the limitation needs to do the following: 1. Set the CRYPTO_HASH_NO_UPDATE flag, in pi_flags field of the crypto_provider_info_t structure, to indicate this limitation. This is a new flag added to spi.h. 2. For each digest mechanism, specify the maximum buffer length it can digest in the cm_max_input_length field in crypto_mech_info_t structure and set the CRYPTO_FG_DIGEST flag in cm_func_group_mask field. 3. Return the error code, CRYPTO_BUFFER_TOO_BIG, if it gets an input buffer greater than the maximum supported length. The framework will use only the digest_init and digest SPI routines from such a provider. It will not use the routines - digest_update, digest_key, and digest_final from the provider. 3.1. Compatibility issues The size of crypto_mech_info_t structure remains unchanged as the field cm_max_input_length is an alias for the existing field, cm_max_key_length. We can safely do this because cm_max_key_length field is unused for a digest mechanism. There is no change in use of cm_max_key_length field for a HMAC mechanism. The framework will get the limit on maximum input data from the underlying digest used by the HMAC mechanism. 4. Bug/RFE Number(s): 6473274 5. Exported Interfaces: +--------------------------------+---------------------------+--------------+ | Interface | Classification | Comments | +--------------------------------+---------------------------+--------------+ | | | | | spi.h | Consolidation | include file | | | Private | | | | | | +--------------------------------+---------------------------+--------------+ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack --Boundary_(ID_GsDrdg4YMF5akZ7982NrMQ)--