From krishna@sac.sfbay.sun.com Tue Oct 6 12:05:27 2009 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 n96J5QIp020960 for ; Tue, 6 Oct 2009 12:05:27 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n96J51t1000949; Tue, 6 Oct 2009 20:05:26 +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 <0KR300I09X0ZYA00@brm-avmta-1.central.sun.com>; Tue, 06 Oct 2009 13:05:23 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR300MMLX0YHQD0@brm-avmta-1.central.sun.com>; Tue, 06 Oct 2009 13:05:22 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n96J5MUC020324; Tue, 06 Oct 2009 12:05:22 -0700 (PDT) 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 n96J5LKa020955; Tue, 06 Oct 2009 12:05:21 -0700 (PDT) Received: (from krishna@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n96J5Li9020951; Tue, 06 Oct 2009 12:05:21 -0700 (PDT) Date: Tue, 06 Oct 2009 12:05:21 -0700 (PDT) From: Krishna Yenduri Subject: CRYPTO_HMAC_NO_UPDATE - A new KCF SPI flag [PSARC/2009/533 Self Review] To: PSARC-ext@sun.com Cc: crypto-discuss@opensolaris.org Message-id: <200910061905.n96J5Li9020951@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3368 I am sponsoring the following self review case for myself. It only modifies consolidation private interfaces and the changes are minor. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CRYPTO_HMAC_NO_UPDATE - A new KCF SPI flag 1.2. Name of Document Author/Supplier: Author: Krishna Yenduri 1.3 Date of This Document: 06 October, 2009 4. Technical Description 4.1 Overview This document describes changes to the Kernel Cryptographic Framework (KCF) SPI to support a new processor. The Interface taxonomy is Consolidation Private. The Release taxonomy is Patch/Micro. 4.2 Problem PSARC/2007/213 introduced a KCF flag, CRYPTO_HASH_NO_UPDATE, that is used by the n2cp driver on the Niagara 2 and the Victoria Falls processors to indicate that there is no hardware support for hash update operations and HMAC update operations. We believed at that time that one flag can cover both hash and HMAC operations. However, this will not be the case for the upcoming Rainbow Falls processor where the hardware can support hash update operations, but it can not support HMAC update operations. So, we need to use a separate flag for these two operations. 4.3 Solution The SPI changes are . Add a new flag, CRYPTO_HMAC_NO_UPDATE, to allow a provider to specify just the no HMAC update limitation. This flag is independent from the existing flag, CRYPTO_HASH_NO_UPDATE, which will now be used to specify just the no hash update limitation. . Discontinue the existing use of cm_max_key_length field in crypto_mech_info_t as a way to pass the maximum input data size a provider can digest. . Instead, the maximum input sizes are set by a provider in crypto_provider_ext_info_t by implementing the ext_info entry point in the co_provider_ops vector. So, these two new fields int ei_hash_max_input_len; int ei_hmac_max_input_len; } crypto_provider_ext_info_t; correspond to the CRYPTO_HASH_NO_UPDATE and CRYPTO_HMAC_NO_UPDATE flags respectively. The CRYPTO_HASH_NO_UPDATE flag is ON consolidation private and only n2cp implements it. So, there is no binary compatibility issue. 4.4 Bug/RFE Number(s): 6886360 4.5 Exported Interfaces +--------------------------------+---------------------------+--------------+ | Interface | Classification | Comments | +--------------------------------+---------------------------+--------------+ | | | | | spi.h | Consolidation | include file | | | Private | | | | | | | common.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: Automatic 6.6. ARC Exposure: open From garrett@damore.org Tue Oct 6 14:15:40 2009 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 n96LFdlP024819 for ; Tue, 6 Oct 2009 14:15:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n96LFdTd014508 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 6 Oct 2009 14:15:39 -0700 (PDT) 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 <0KR400E15322NB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 06 Oct 2009 14:15:38 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR4009YS321FF60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 06 Oct 2009 14:15:38 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n96LBaB2020634 for ; Tue, 06 Oct 2009 21:15:37 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-292876 for PSARC-ext@Sun.Com; Tue, 06 Oct 2009 21:15:37 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-62746671 for PSARC-ext@Sun.Com; Tue, 06 Oct 2009 21:15:36 +0000 (Z) Received: from outbound-mail-129.bluehost.com ([67.222.38.29] [67.222.38.29]) by relay1i.sun.com id BT-MMP-22195324 for PSARC-ext@Sun.Com; Tue, 06 Oct 2009 21:15:36 +0000 (Z) Received: (qmail 8000 invoked by uid 0); Tue, 06 Oct 2009 21:15:36 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy4.bluehost.com with SMTP; Tue, 06 Oct 2009 21:15:36 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MvHNg-0008AU-0i; Tue, 06 Oct 2009 15:15:36 -0600 Date: Tue, 06 Oct 2009 14:15:34 -0700 From: "Garrett D'Amore" Subject: Re: CRYPTO_HMAC_NO_UPDATE - A new KCF SPI flag [PSARC/2009/533 Self Review] In-reply-to: <200910061905.n96J5Li9020951@sac.sfbay.sun.com> To: Krishna Yenduri Cc: PSARC-ext@sun.com, crypto-discuss@opensolaris.org Message-id: <4ACBB376.7070604@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=f752wS5DssAz+Dx3ZcjK1Pt20gCwNHCionNeqfngFd/xBwXHgZV1THieUrK/XVQErvt3TEFpbP3X05Nw+72eacMCfmLYCUpkapMVmj+hPA/ZaEiz1XFkYvdwBZp2g5rE; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} References: <200910061905.n96J5Li9020951@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3749 +1. - Garrett Krishna Yenduri wrote: > I am sponsoring the following self review case for myself. It only > modifies consolidation private interfaces and the changes are minor. > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > CRYPTO_HMAC_NO_UPDATE - A new KCF SPI flag > 1.2. Name of Document Author/Supplier: > Author: Krishna Yenduri > 1.3 Date of This Document: > 06 October, 2009 > 4. Technical Description > > 4.1 Overview > > This document describes changes to the Kernel Cryptographic Framework (KCF) > SPI to support a new processor. > > The Interface taxonomy is Consolidation Private. > The Release taxonomy is Patch/Micro. > > 4.2 Problem > > PSARC/2007/213 introduced a KCF flag, CRYPTO_HASH_NO_UPDATE, that is used > by the n2cp driver on the Niagara 2 and the Victoria Falls processors to > indicate that there is no hardware support for hash update operations > and HMAC update operations. > > We believed at that time that one flag can cover both hash and > HMAC operations. However, this will not be the case for the upcoming > Rainbow Falls processor where the hardware can support hash update operations, > but it can not support HMAC update operations. > > So, we need to use a separate flag for these two operations. > > 4.3 Solution > > The SPI changes are > > . Add a new flag, CRYPTO_HMAC_NO_UPDATE, to allow a provider to specify > just the no HMAC update limitation. This flag is independent from the > existing flag, CRYPTO_HASH_NO_UPDATE, which will now be used to specify > just the no hash update limitation. > > . Discontinue the existing use of cm_max_key_length field in > crypto_mech_info_t as a way to pass the maximum input data size a provider > can digest. > > . Instead, the maximum input sizes are set by a provider in > crypto_provider_ext_info_t by implementing the ext_info entry point in the > co_provider_ops vector. > > So, these two new fields > int ei_hash_max_input_len; > int ei_hmac_max_input_len; > } crypto_provider_ext_info_t; > > correspond to the CRYPTO_HASH_NO_UPDATE and CRYPTO_HMAC_NO_UPDATE flags > respectively. > > The CRYPTO_HASH_NO_UPDATE flag is ON consolidation private and only n2cp > implements it. So, there is no binary compatibility issue. > > 4.4 Bug/RFE Number(s): 6886360 > > 4.5 Exported Interfaces > > +--------------------------------+---------------------------+--------------+ > | Interface | Classification | Comments | > +--------------------------------+---------------------------+--------------+ > | | | | > | spi.h | Consolidation | include file | > | | Private | | > | | | | > | common.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: Automatic > 6.6. ARC Exposure: open > > _______________________________________________ > crypto-discuss mailing list > crypto-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crypto-discuss >