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

net80211: add placeholder module names for the new ciphers

This is effectively a no-op as we currently don't advertise these
ciphers as available anywhere.

Note though the intent to support 128 and 256 bit ciphers in the same
crypto module.

Differential Revision: https://reviews.freebsd.org/D44900
Reviewed by: cc, cy
Approved by: cc, cy

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

net80211: add a new field specifically for announcing specific ciphers

This dates way, way back with the original net80211 support w/ atheros chips.

The earliest chip (AR5210) had limitations supporting software encryption.
It only had the four WEP slots, and not any keycache entries. So when
trying to do CCMP/TKIP encryption would be enabled and the key slots
would have nothing useful in them, resulting in garbage encryption/decryption.

I changed this back in 2012 to disable supporting hardware WEP for AR5210
so if_ath(4) / net80211 crypto is all done in software and yes,
I could do CCMP/TKIP on AR5210 in software.

Fast-forward to newer-ish hardware - the Qualcomm 11ac hardware.
Those also don't support pass-through keycache slots! Well, the hardware
does at that layer, but then there's a whole offload data path encap/decap
layer that's turning the frames from raw wifi into ethernet frames (for
"dumb" AP behaviours) or "wifi direct" frames (ie, "windows".)
This hides a bunch of header frame contents required for doing the software
encryption / decryption path.

But then if you enable the raw transmit/receive frame format it ALSO
bypasses the hardware encryption/decryption engine!

So for those NICs:

* If you want to do encryption, you can only use the firmware supported
ciphers w/ wifi direct or ethernet;
* If you want to use software encrypt/decrypt, you MUST disable all encryption
and instead use 100% software encryption.

The wpa_supplicant bsd driver code has a specific comment about this and
flips on supporting WEP/TKIP/CCMP, which is understandable but it doesn't
fix the ACTUAL intention of all of this stuff.

So:

* create a new field, ic_sw_cryptocaps
* populate it with the default supported set of ciphers for net80211
(right now wep, tkip, ccmp)
* Communicate the combination of both ic_sw_cryptocaps and ic_cryptocaps
to wpa_supplicant via the relevant devcap ioctl.
* Update manpage.

I'll follow this up with a driver_bsd.c change in wpa_supplicant to
trust this again, and then start adding the other cipher support there.

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

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\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 BSD-2-Clause.

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

net80211: fail for unicast traffic without unicast key

Falling back to the multicast key may cause unicast traffic to leak.
Instead fail when no key is found.

For more information see the 'Framing Frames: Bypassing Wi-Fi Encryption
by Manipulating Transmit Queues' paper.

[ I updated the commit message to reference the paper and the code
comment to record historic behaviour as discussed in private email. ]

Security: CVE-2022-47522

net: clean up empty lines in .c and .h files

net80211: drop m_pullup call from ieee80211_crypto_decap.

For most wireless drivers Rx mbuf is allocated as one
contiguous chunk; only few are using chains for allocations -
but even then at least MCLBYTES (minus Rx descriptor size) is
available in the first mbuf.

In addition to the above, m_pullup was never called here - otherwise,
reallocation will break post-crypto_decap logic (ieee80211_decap,
ieee80211_deliver_data...), so just remove it; length check is left
in case if some truncated frame appears here.

PR: 234241
MFC after: 1 week

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.

[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

net80211 + drivers: convert to ieee80211_crypto_get_key_wepidx().

Proposed by: adrian

Fix typo.

[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.

[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

[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

net80211: drop redundant 3rd parameter from iv_key_set().

The MAC can be fetched from the key struct.

I added the ndis updates to make it compile.

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

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

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

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

Move counter.h include into ieee80211_freebsd.h. Should fix build.

Submitted by: Zilvinas Valinskas <zilvinas.valinskas gmail.com>

Add two counters to ieee80211com, that will be used to count transmission
or receive errors that can't be associated with any vap.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Correct handling of keys that already have a hardware/device key index:
this was broken in r183248 when the check of wk_keyix was replaced by
a check of IEEE80211_KEY_DEVKEY (because the flag was clobbered). Define
IEEE80211_KEY_DEVICE to specify flags that are owned by net80211/driver
and use this to preserve IEEE80211_KEY_DEVKEY so we don't ask the driver
for another key index when we already have one.

Testing by: Daniel Thiele, Wes Morgan
Reviewed by: rpaulo
Approved by: re (kib)

use c99-style initializers

add/improve debug msgs

- Import the HEAD csup code which is the basis for the cvsmode work.

Crypto api changes:
o don't use the key index to identify when the driver has been
asked to allocate a key slot, use an explicit flag; allows
drivers to force s/w fallback for entries in the global table
o change callback api to allocate driver resources for a crypto key:
- de-const the key parameter so drivers can muck with the flags
- on callback failure don't automatically try to setup s/w crypto;
instead the driver must now mark the key entry for s/w crypto and
the caller will re-attach the cipher module

NB: api change permits drivers more control over fallback to s/w
crypto (e.g. based on a limited number of h/w key slots)

Add ieee80211_crypto_reload_keys to push all keys known
to net80211 back into the device; intended for use on resume
by devices that lose the contents of their h/w key table.

Add a mac address to the key definition as otherwise we lose the
address specified in the ioctl and for drivers that need the address
to locate a key (e.g. for delete).

Note this changes net80211-private api's but not the driver callback;
may want to change that in the future.

Reviewed by: sephe, thompsa

Multi-bss (aka vap) support for 802.11 devices.

Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral). Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.

Supported by: Hobnob and Marvell
Reviewed by: many
Obtained from: Atheros (some bits)

Update 802.11 wireless support:
o major overhaul of the way channels are handled: channels are now
fully enumerated and uniquely identify the operating characteristics;
these changes are visible to user applications which require changes
o make scanning support independent of the state machine to enable
background scanning and roaming
o move scanning support into loadable modules based on the operating
mode to enable different policies and reduce the memory footprint
on systems w/ constrained resources
o add background scanning in station mode (no support for adhoc/ibss
mode yet)
o significantly speedup sta mode scanning with a variety of techniques
o add roaming support when background scanning is supported; for now
we use a simple algorithm to trigger a roam: we threshold the rssi
and tx rate, if either drops too low we try to roam to a new ap
o add tx fragmentation support
o add first cut at 802.11n support: this code works with forthcoming
drivers but is incomplete; it's included now to establish a baseline
for other drivers to be developed and for user applications
o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates
prepending mbufs for traffic generated locally
o add support for Atheros protocol extensions; mainly the fast frames
encapsulation (note this can be used with any card that can tx+rx
large frames correctly)
o add sta support for ap's that beacon both WPA1+2 support
o change all data types from bsd-style to posix-style
o propagate noise floor data from drivers to net80211 and on to user apps
o correct various issues in the sta mode state machine related to handling
authentication and association failures
o enable the addition of sta mode power save support for drivers that need
net80211 support (not in this commit)
o remove old WI compatibility ioctls (wicontrol is officially dead)
o change the data structures returned for get sta info and get scan
results so future additions will not break user apps
o fixed tx rate is now maintained internally as an ieee rate and not an
index into the rate set; this needs to be extended to deal with
multi-mode operation
o add extended channel specifications to radiotap to enable 11n sniffing

Drivers:
o ath: add support for bg scanning, tx fragmentation, fast frames,
dynamic turbo (lightly tested), 11n (sniffing only and needs
new hal)
o awi: compile tested only
o ndis: lightly tested
o ipw: lightly tested
o iwi: add support for bg scanning (well tested but may have some
rough edges)
o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data
o wi: lightly tested

This work is based on contributions by Atheros, kmacy, sephe, thompsa,
mlaier, kevlo, and others. Much of the scanning work was supported by
Atheros. The 11n work was supported by Marvell.

copyright updates:
o update to include 2007
o switch back to a 2-clause bsd-only license

Reviewed by: onoe

white space diff reduction

add IEEE80211_KEY_UNDEFINED and use it instead of local defs

Obtained from: netbsd

Split crypto tx+rx key indices and add a key index -> node mapping table:

Crypto changes:
o change driver/net80211 key_alloc api to return tx+rx key indices; a
driver can leave the rx key index set to IEEE80211_KEYIX_NONE or set
it to be the same as the tx key index (the former disables use of
the key index in building the keyix->node mapping table and is the
default setup for naive drivers by null_key_alloc)
o add cs_max_keyid to crypto state to specify the max h/w key index a
driver will return; this is used to allocate the key index mapping
table and to bounds check table loookups
o while here introduce ieee80211_keyix (finally) for the type of a h/w
key index
o change crypto notifiers for rx failures to pass the rx key index up
as appropriate (michael failure, replay, etc.)

Node table changes:
o optionally allocate a h/w key index to node mapping table for the
station table using the max key index setting supplied by drivers
(note the scan table does not get a map)
o defer node table allocation to lateattach so the driver has a chance
to set the max key id to size the key index map
o while here also defer the aid bitmap allocation
o add new ieee80211_find_rxnode_withkey api to find a sta/node entry
on frame receive with an optional h/w key index to use in checking
mapping table; also updates the map if it does a hash lookup and the
found node has a rx key index set in the unicast key; note this work
is separated from the old ieee80211_find_rxnode call so drivers do
not need to be aware of the new mechanism
o move some node table manipulation under the node table lock to close
a race on node delete
o add ieee80211_node_delucastkey to do the dirty work of deleting
unicast key state for a node (deletes any key and handles key map
references)

Ath driver:
o nuke private sc_keyixmap mechansim in favor of net80211 support
o update key alloc api

These changes close several race conditions for the ath driver operating
in ap mode. Other drivers should see no change. Station mode operation
for ath no longer uses the key index map but performance tests show no
noticeable change and this will be fixed when the scan table is eliminated
with the new scanning support.

Tested by: Michal Mertl, avatar, others
Reviewed by: avatar, others
MFC after: 2 weeks

don't include 802.3 header in min frame length calculation as it may
not be present for a frag; fixes problem with small (fragmented) frames
being dropped

Obtained from: Atheros
MFC after: 3 days

Change default key allocation method to do the right thing for
legacy parts (i.e. those that have 4 global key slots). We
blindly assign unicast keys to key slot 0. Devices that need
alternate allocation logic must override this method.

Reviewed by: avatar
Approved by: re (scottl)

o fix wpa w/ wme: don't strip the QoS header on recv as tkip requires
it; instead pass the space occupied by the header down into the
crypto modules (except in the demic case which needs it only when
doing int in s/w)
o while here fix defrag to strip the header from 2nd and later frames
o teach decap code how to handle 4-address frames

Revise crypto api lightly to improve group key handling:
o don't pre-assign key index to the global key table entries so device
has a chance to decide what to use
o make ieee80211_crypto_newkey take the desired flags as an argument
instead of wacking the key structure directly; this eliminates a
bunch of code warts
o add a new flag IEEE80211_KEY_GROUP to indicate a key is a WPA Group
key so devices don't need to guess (temporarily add this flag in the
ioctl code until we can get wpa_supplicant+hostapd updated)
o shuffle IEEE80211_KEY_* bits to move flags used internally to the high
nibble of the flags word

Reviewed by: Tai-hwa Liang

bump copyright for 2005

const'ify ivp reference

add/fixup debug msgs

Update 802.11 support; too much new functionality to fully describe
here but it includes completed 802.11g, WPA, 802.11i, 802.1x, WME/WMM,
AP-side power-save, crypto plugin framework, authenticator plugin framework,
and access control plugin frameowrk.

add statistics for all failures and/or abnormal events; still need
to add per-node statistics

revise copyright notices per discussion with Atsushi Onoe <onoe@sm.sony.co.jp>

new 802.11 layer:

o code reorg (relative to old netbsd-derived code) for future growth
o drivers now specify available channels and rates and 802.11 layer handles
almost all ifmedia actions
o multi-mode support for 11a/b/g devices
o 11g protocol additions (incomplete)
o new element id additions (for other than 11g)
o node/station table redone for proper locking and to eliminate driver
incestuousness
o split device flags and capabilities to reduce confusion and provide room
for expansion
o incomplete power management infrastructure (need to revisit)
o incomplete hooks for software retry
o more...