net80211: correct typo s/Insure/Ensure/

No functional changes.

Sposnored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D48358

net80211: migrate the group/unicast key check into inline functions

The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's

net80211: migrate the group/unicast key check into inline functions

The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's a group
key. If not, it's a unicast key.

That's not only kind of terrible, but it's also going to be
problematic with future 802.11 support (for multiple unicast keys
and IGTK keys for management frame protection.)

So as part of this, remove the places where this is done and
instead use a pair inline functions - ieee80211_is_key_global() and
ieee80211_is_key_unicast(). They currenly still use the same logic
but the drivers and net80211 stack isn't doing it itself.

There are still open questions about why keys are not being
correctly tagged as GROUP, GTK, PTK, etc. That will be investigated
and addressed in follow-up work as a pre-cursor to MFP, IGTK, etc.
as mentioned above.

Testing:

* iwn, rtwn - STA mode

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

show more ...

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

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

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

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 suppo

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

show more ...

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

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

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

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

show more ...

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 M

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

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

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 from head

Sponsored by: Gandi.net

Merge from head

Sync up with head up to r289211.

Merge from head