cvs commit: src/sys/netproto/802_11 ieee80211_crypto.h ieee80211_proto.h ieee80211_var.h src/sys/netproto/802_11/wlan ieee80211_crypto.c ieee80211_crypto_none.c ieee80211_input.c ieee80211_output.c src/sys/netproto/802_11/wlan_ccmp ieee80211_crypto_ccmp.c src/sys/netproto/802_11/wlan_tkip ...

[Sepherosa Ziehau <sephe@xxxxxxxxxxxxxxxxxxxxxxx>]

sephe       2007/05/07 07:12:16 PDT

DragonFly src repository

  Modified files:
    sys/netproto/802_11  ieee80211_crypto.h ieee80211_proto.h 
                         ieee80211_var.h 
    sys/netproto/802_11/wlan ieee80211_crypto.c 
                             ieee80211_crypto_none.c 
                             ieee80211_input.c ieee80211_output.c 
    sys/netproto/802_11/wlan_ccmp ieee80211_crypto_ccmp.c 
    sys/netproto/802_11/wlan_tkip ieee80211_crypto_tkip.c 
    sys/netproto/802_11/wlan_wep ieee80211_crypto_wep.c 
  Log:
  Adapt 802.11 generic layer to support hardware crypto other than ath(4).
  More specificly, it is changed for Wifi chips from Ralink (2x61 is used
  as an example here), which have following hardware crypto features.  These
  features are different from ath(4)'s and need special cares:
  1) For TX, host does not need to insert IV and Extended IV after 802.11 MAC
     header, instead, host provides them in TX descriptor.
  2) For RX, IV and Extended IV will not be left in RX buffer, instead, they
     are recorded in RX descriptor.
  3) For RX and TKIP is used as crypto method, if the received MPDU is the
     only fragment of an MSDU then MIC is stripped and hardware will verify
     MIC for host.
  
  Since these kinds of hardwares need to know IV and Extended IV,
  ieee80211_crypto_iv structure is added.  It can hold IV and Extended IV, and
  is used to pass these two IVs to and from 802.11 generic layer.  It requires
  a special layout to ease crypto modules' processing, so comment is added to
  make sure the structure's layout will not be changed.
  
  To address the problems introduced by the hardware feature 1), following
  changes are made:
  - Add ic_getiv() interface for all crypto modules, which is (obviously) used
    to get IV and extended IV from crypto module.  Except that it puts IVs in
    ieee80211_crypto_iv instead of TX buffer, the new interface is quite similar
    to ic_encap().  Wrap ic_getiv() interface by ieee80211_crypto_getiv().
  - Split ieee80211_crypto_encap() into two functions:
    o  ieee80211_crypto_findkey().  It is used to find the crypto key for given
       MPDU and receiver.
    o  ieee80211_crypto_encap_withkey().  It does the real encryption work.
       For Ralink's Wifi chips, this function is only called when host based
       encryption is used.
    After this splition, driver will have a chance to decide whether it need to
    do host encryption, which could happen when there are not enough hardware
    pairwise keys, or offload the encryption to hardware.  ath(4) does not need
    this interception, since no matter hardware encryption is used or not, host
    always has to insert IVs, while for Ralink Wifi chips, IV insertion can be
    done only if host encryption is to be used, for hardware encryption, they
    must be set in TX descriptor.
    This splition also causes another problem:
    ieee80211_crypto_encap_withkey() requires a keyid (read: not key index) and
    it will be too bloated to add a keyid parameter for both
    ieee80211_crypto_encap_withkey() and ieee80211_crypto_findkey(), so
    o  Change ieee80211_key.wk_pad to ieee80211_key.wk_keyid, which is keyid for
       a given key, and is set in ieee80211_crypto_resetkey().  Since
       ieee80211_crypto_resetkey() will need to know internals of ieee80211com,
       put it into ieee80211_crypto.c.
    o  Add assertion in ieee80211_crypto_findkey() to make sure that the crypto
       key has correct keyid.
    o  Make ieee80211_crypto_encap() a wrapper of ieee80211_crypto_findkey() and
       ieee80211_crypto_encap_withkey().  Old symantic of this function is still
       kept.
    The crypto encapsulation for Ralink Wifi chips will look like following:
    ...
    k = ieee80211_crypto_findkey();
    if (k is hardware encryption key)
        k = ieee80211_crypto_getiv(k, iv);
    else
        k = ieee80211_crypto_encap_withkey(k);
    ...
  - Add a crypto key flag, IEEE80211_KEY_NOHDR, to indicate that host does not
    need to reserve space in TX buffer if hardware encryption is used.
  - Honor IEEE80211_KEY_NOHDR in ieee80211_mbuf_adjust().
  - Add an extended capability flag, IEEE80211_CEXT_CRYPTO_HDR, which is set by
    driver to inform crypto module that if hardware encryption is used for a
    crypto key, the key should have IEEE80211_KEY_NOHDR turned on.
  
  To address the problems introduced by the hardware feature 2), following
  changes are made:
  - Add ic_update() interface for all crypto modules, which is used to update
    crypto modules' internal state according to the IVs passed in.  Except that
    it peeks at the passed in ieee80211_crypto_iv instead of RX buffer, it acts
    similarly to ic_decap().  Wrap ic_update() interface by
    ieee80211_crypto_update().  ieee80211_crypto_update() also locates the crypto
    key for given MPDU and sender.
  - Add ieee80211_input_withiv(), which accepts an ieee80211_crypto_iv 'iv'
    parameter in addition to the original ieee80211_input() parameters.  If 'iv'
    parameter is NULL, old ieee80211_input() behaviour is used, if 'iv' is not
    NULL, ieee80211_crypto_update() will be called instead of
    ieee80211_crypto_decap().  ath(4) does not require this special processing,
    since no matter hardware encryption is used or not, IVs are always in RX
    buffer, but for Wifi chips from Ralink, we will have to explicitly pass the
    recorded IVs in RX descriptor down to crypto modules.
  - Change ieee80211_input() to call ieee80211_input_withiv() with NULL 'iv'.
    Old symantic of this function is still kept.
  
  To address the problems introduced by the hardware feature 3), following
  changes are made:
  - Add a key flag, IEEE80211_KEY_NOMIC, to give hint to TKIP crypto module that
    hardware will strip TKIP MIC.
  - Honor IEEE80211_KEY_NOMIC in tkip_demic().
  - Add an extended capability flag, IEEE80211_CEXT_STRIP_MIC, which is set by
    driver to inform crypto module that if hardware TKIP MIC is used for a
    crypto key, then the key should have IEEE80211_KEY_NOMIC turned on.
  
  Revision  Changes    Path
  1.4       +30 -16    src/sys/netproto/802_11/ieee80211_crypto.h
  1.13      +4 -0      src/sys/netproto/802_11/ieee80211_proto.h
  1.16      +6 -0      src/sys/netproto/802_11/ieee80211_var.h
  1.6       +84 -6     src/sys/netproto/802_11/wlan/ieee80211_crypto.c
  1.3       +42 -0     src/sys/netproto/802_11/wlan/ieee80211_crypto_none.c
  1.20      +21 -3     src/sys/netproto/802_11/wlan/ieee80211_input.c
  1.21      +2 -1      src/sys/netproto/802_11/wlan/ieee80211_output.c
  1.5       +65 -0     src/sys/netproto/802_11/wlan_ccmp/ieee80211_crypto_ccmp.c
  1.5       +100 -4    src/sys/netproto/802_11/wlan_tkip/ieee80211_crypto_tkip.c
  1.5       +51 -0     src/sys/netproto/802_11/wlan_wep/ieee80211_crypto_wep.c


http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/ieee80211_crypto.h.diff?r1=1.3&r2=1.4&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/ieee80211_proto.h.diff?r1=1.12&r2=1.13&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/ieee80211_var.h.diff?r1=1.15&r2=1.16&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan/ieee80211_crypto.c.diff?r1=1.5&r2=1.6&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan/ieee80211_crypto_none.c.diff?r1=1.2&r2=1.3&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan/ieee80211_input.c.diff?r1=1.19&r2=1.20&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan/ieee80211_output.c.diff?r1=1.20&r2=1.21&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan_ccmp/ieee80211_crypto_ccmp.c.diff?r1=1.4&r2=1.5&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan_tkip/ieee80211_crypto_tkip.c.diff?r1=1.4&r2=1.5&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan_wep/ieee80211_crypto_wep.c.diff?r1=1.4&r2=1.5&f=u