net80211: add initial key management suites from 802.11-2016, APIs to register them

The WPA1/WPA2 driver capabilities aren't really enough in today's world.
There are a /lot/ more key management sui

net80211: add initial key management suites from 802.11-2016, APIs to register them

The WPA1/WPA2 driver capabilities aren't really enough in today's world.
There are a /lot/ more key management suites to support!

So, add initial support for net80211 and drivers to announce what
key management suites are supported. These are the list from 802.11-2016
section 9.4.2.25.3 (AKM suites.)

The flags are for software supported key management.

Drivers may support more key management suites and are welcome to
announce more; net80211 will only announce ones that we know
net80211 knows "enough" about to support correctly.

There /are/ other suites that may be interesting to some people in
the future that are not part of this set - eg if anyone ever
wants to support the Chinese WAPI standard - so this bitmap is not
specifically just the AKM suites in the RSN OUI.

This should eventually be communicated up to the wpa_supplicant and
hostapd via a replacement driver/vap capabilities call so they know
what to enable rather than just IEEE80211_C_WPA1 / IEEE80211_C_WPA2.

Differential Revision: https://reviews.freebsd.org/D44919
Reviewed by: bz

show more ...

net80211: add the 802.11-2016 cipher list to the crypto array set.

These are the bitmap / cipher module number fields used for net80211
ciphers.

This requires a kernel recompile, but nothing (curre

net80211: add the 802.11-2016 cipher list to the crypto array set.

These are the bitmap / cipher module number fields used for net80211
ciphers.

This requires a kernel recompile, but nothing (currently) in userland
is using these.

Differential Revision: https://reviews.freebsd.org/D44899
Reviewed by: bz, cc

show more ...

net80211: add driver / crypto methods to set the hardware / software cipher suites

Drivers currently announce hardware crypto cipher support by
setting up ic_cryptocaps.

This adds two public functi

net80211: add driver / crypto methods to set the hardware / software cipher suites

Drivers currently announce hardware crypto cipher support by
setting up ic_cryptocaps.

This adds two public function calls:

* ieee80211_set_software_ciphers() - set the software cipher set;
* ieee80211_set_hardware_ciphers() - set the hardware cipher set.

For now these just call into the newly crypto routines to set the ciphers.

This then adds the two crypto routines, similarly named, to set
the hardware/software cipher suite.

This is a no-op right now - wep/tkip/ccmp are already set by default
so drivers aren't required to call these routines for software
encryption, and drivers already set ic_cryptocaps for hardware
encryption.

Differential Revision: https://reviews.freebsd.org/D44827

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
pro

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

No functional change intended.

show more ...

[net80211] turn the default TX key configuration (for WEP) into a vap callback.

The ath10k firmware supports hardware WEP offload, and in native wifi mode
(or 802.3 ethernet mode, for that matter) t

[net80211] turn the default TX key configuration (for WEP) into a vap callback.

The ath10k firmware supports hardware WEP offload, and in native wifi mode
(or 802.3 ethernet mode, for that matter) the WEP key isn't actually included
in the TX payload from net80211. Instead, a separate firmware command is issued
that sets the default TX key to be the specified key.

However, net80211 doesn't at all inform the driver layer that this is
occuring - it just "expects" to be inserting WEP header information
when doing WEP TX, even with hardware encryption.

So, to better support the newer world order, turn the default TX key assignment
into a VAP method that can be overridden by the driver and ensure its wrapped
in a crypto begin/end set. That way it should be correctly atomic from the
point of view of keychanges (as long as the driver does the right thing.)

It'd be nice if we passed through to the key_set call a flag that says
"also make this the default key" - that's captured here by calling the
deftxkey method after the key_set method. Maybe I can do that later.

Note: this is a net80211 ABI change, and will require a kernel+modules
recompile. Happy Holidays, etc.

Tested:

* ath10k driver port
* rtwn_usb, WEP station

show more ...

Merge ^/head r309519 through r309757.

[net80211] start refactoring out the "am I a wep / group key!" code.

This is a bunch of pointer arithmetic that is copypasta'ed everywhere.
Let's undo that copypasta.

Merge ^/head r308491 through r308841.

[net80211] handle hardware encryption offload in the receive path

* teach the crypto modules about receive offload - although I have
to do some further reviewing in places where we /can't/ have an

[net80211] handle hardware encryption offload in the receive path

* teach the crypto modules about receive offload - although I have
to do some further reviewing in places where we /can't/ have an RX key
* teach the RX data path about receive offload encryption - check the flag,
handle NULL key, do decap and checking as appropriate.

Tested:

* iwn(4), STA mode
* ath(4), STA and AP mode
* ath10k port, STA mode (hardware encryption)

Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8533

show more ...

Merge ^/head r308227 through r308490.

[net80211] begin fleshing out new hardware crypto offload features.

* extend the keycache flag word to be 32 bits, not 16 bits
* add new key flags for transmit:
+ IEEE80211_KEY_NOIV: Don't insert

[net80211] begin fleshing out new hardware crypto offload features.

* extend the keycache flag word to be 32 bits, not 16 bits
* add new key flags for transmit:
+ IEEE80211_KEY_NOIV: Don't insert IV in the payload when transmitting data frames;
+ IEEE80211_KEY_NOIVMGT: Don't insert IV in the payload when transmitting MIC frames;
+ IEEE80211_KEY_NOMIC: Don't insert MIC in the payload when transmitting data frames;
+ IEEE80211_KEY_NOMICMGT: don't insert MIC in the payload when transmitting management
frames.

* teach ieee80211_crypto_demic() about hardware decrypted frames:
+ if frames are hardware decrypted and the frame has failed MIC, treat it as a
michael failure.
+ if frames are hardware decrypted and the frame has stripped MIC, we can't check the
MIC in the payload - we don't have anything to compare it against.

This is only part of the work required to successfully transmit/receive
hardware crypto frames such as the qualcomm atheros 11ac offload chips.

There will be further work in the transmit and receive path before this
can be done by default.

Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8364

show more ...

Merge ^/head r305687 through r305890.

net80211: allow to override SWCRYPT/SWMIC bits in the driver

Add IEEE80211_KEY_SWCRYPT / IEEE80211_KEY_SWMIC bits to the
IEEE80211_KEY_DEVICE mask - as a result, those bits will be preserved
during

net80211: allow to override SWCRYPT/SWMIC bits in the driver

Add IEEE80211_KEY_SWCRYPT / IEEE80211_KEY_SWMIC bits to the
IEEE80211_KEY_DEVICE mask - as a result, those bits will be preserved
during group key handshake.

A driver can override them in iv_key_alloc() for some keys in case
when hardware crypto support is not possible. As an example:
- multi-vap without multicast key search support;
- IBSS RSN for devices w/ fixed storage for group keys;

Tested with RTL8188EU (AP, sw crypto) and
RTL8821AU (STA, sw crypto for group keys + hw crypto for pairwise keys)

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D7901

show more ...

Merge from head

Sponsored by: Gandi.net

Merge from head

Sync up with head up to r289211.

Merge from head

Merge ^/head r288457 through r288830.

net80211: add a possibility to retrieve current TX key without encapsulation.

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3639

net80211: add new method for ieee80211_cipher (ic_setiv).

This can be used to update IV state for the caller without adding
information to the mbuf. Some hardware (eg rum) apparently requires
bits

net80211: add new method for ieee80211_cipher (ic_setiv).

This can be used to update IV state for the caller without adding
information to the mbuf. Some hardware (eg rum) apparently requires
bits of this.

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3638

show more ...

net80211: separate ieee80211_crypto_get_keyid() from ieee80211_crypto_encap()

Tested:

* rum(4), STA mode
* rsu(4), STA mode
* urtwn(4), STA mode

Submitted by: <s3erios@gmail.com>
Differential Revi

net80211: separate ieee80211_crypto_get_keyid() from ieee80211_crypto_encap()

Tested:

* rum(4), STA mode
* rsu(4), STA mode
* urtwn(4), STA mode

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3637

show more ...

Merge svn+ssh://svn.freebsd.org/base/head@209749

- Introduce IEEE80211_KEY_NOREPLAY, a per-key flag to ignore replay
violations.
- Use SIOCGIFMEDIA to determine VAP's opmode, cache it and set
IEEE80211_KEY_NOREPLAY for AHDEMO and IBSS.

Approve

- Introduce IEEE80211_KEY_NOREPLAY, a per-key flag to ignore replay
violations.
- Use SIOCGIFMEDIA to determine VAP's opmode, cache it and set
IEEE80211_KEY_NOREPLAY for AHDEMO and IBSS.

Approved by: rpaulo (mentor)

show more ...