Page MenuHomeFreeBSD

net80211: create accessors for accessing the ieee80211_key key/mic data
Needs RevisionPublic

Authored by adrian on Sep 24 2025, 3:35 PM.
Referenced Files
Unknown Object (File)
Thu, Oct 23, 11:10 PM
Unknown Object (File)
Sun, Oct 19, 2:35 AM
Unknown Object (File)
Sat, Oct 18, 9:32 AM
Unknown Object (File)
Fri, Oct 17, 1:44 PM
Unknown Object (File)
Wed, Oct 15, 4:51 AM
Unknown Object (File)
Tue, Oct 14, 6:19 PM
Unknown Object (File)
Tue, Oct 14, 3:31 PM
Unknown Object (File)
Sat, Oct 11, 9:06 PM

Details

Reviewers
thj
bz
Group Reviewers
wireless
Summary

Add some accessors to the key data, key length and MIC data.
Document exactly what these mean.

There's at least a couple of drivers that access the key data field
directly and assume that the TX/RX MIC is available directly after the
data pointer, which bakes in the "key size is 128 bits" in subtle ways.

The goal here is to migrate the drivers and net80211 code to use
these methods rather than accessing wk_key directly and making assumptions
about wk_key and the copied key length (which the ioctl path definitely
does.)

Once that's done, it should be a lot easier to change the key API for
larger keys.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 67281
Build 64164: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Sep 30 2025, 10:22 AM
bz requested changes to this revision.Oct 4 2025, 3:32 PM
bz added a subscriber: bz.
bz added inline comments.
sys/net80211/ieee80211_crypto.h
312

Just commenting on the first entry. So should this happen only during a iv_key_update_begin/end session, and if so should we make sure we can assert this?

This revision now requires changes to proceed.Oct 4 2025, 3:32 PM
sys/net80211/ieee80211_crypto.h
312

no, this happens during transmit/receive handling. only key alloc / key set happens inside the key update begin/end session.

That said, those should likely get some kind of runtime checks and printing warnings / assertions if they are called outside of it.

sys/net80211/ieee80211_crypto.h
312

Oh, sorry, with full offloading key access is only needed during key operations. My fault.

But then your comment isn't all right either as it would require holding the com lock for the keys to not disappear and most transmit routines probably do not want that?

sys/net80211/ieee80211_crypto.h
312

Well, yeah, there are a lot of assumptions in net80211 when the rug can be pulled out from underneath various parallel things. A lot of things weren't once runnable in parallelable contexts!

The key rug pull is one of the big reasons why there aren't dynamic keys allocated; in theory as long as the node / vap exists, the key pointers will point to something valid, even if the contents are changed from underneath them.

So yeah, we should definitely add "clean up key management locking / sequencing with transmit and receive paths", but that's not part of this diff set! (And it gets spicy, because do you REALLY want to halt all traffic during key changes? Sometimes the answer is yes, sometimes the answer is no..)

312

hm, but re-reading my comment, I'll go turn it into more of a warning and explain things a bit. Stay tuned!